Maybe not exactly what you want, but it sounds to me like you have different versions of Perl, potentially different bit-tedness and want to be able to install / compile modules correctly for each one.

I do this in Windows with a batch script. See Re: Multiple Strawberry Perl Versions under Windows for details.

Essentially, I'm pointing the C:\Strawberry directory to the root installation directory of any version of Perl on my system. That way, no changes to PATH are needed and from the command prompt, 'perl' will always run and be whatever version, and with all the proper associations (gcc, as, ar, etc.) for that specific version.

My default:

VinsWorldcom@C:\Users\VinsWorldcom> perl -v

This is perl 5, version 18, subversion 1 (v5.18.1) built for MSWin32-x
+64-multi-thread

[....]

VinsWorldcom@C:\Users\VinsWorldcom> as --version
GNU assembler (GNU Binutils) 2.23.2
Copyright 2012 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms
+ of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `x86_64-w64-mingw32'.
[download]

Now let's switch to Perl 5.8 32-bit:

VinsWorldcom@C:\Users\VinsWorldcom> perlreloc.bat 5.8.8-MSWin32-x86-mu
+lti-thread

Junction v1.06 - Windows junction creator and reparse point viewer
Copyright (C) 2000-2010 Mark Russinovich
Sysinternals - www.sysinternals.com

Deleted c:\strawberry.

Junction v1.06 - Windows junction creator and reparse point viewer
Copyright (C) 2000-2010 Mark Russinovich
Sysinternals - www.sysinternals.com

Created: c:\strawberry
Targetted at: c:\strawberry_5.8.8-MSWin32-x86-multi-thread
5.008008  @  C:\strawberry\perl\bin\perl.exe
[download]

...and verify

VinsWorldcom@C:\Users\VinsWorldcom> perl -v

This is perl, v5.8.8 built for MSWin32-x86-multi-thread

[...]

VinsWorldcom@C:\Users\VinsWorldcom> as --version
GNU assembler 2.17.50 20060824
Copyright 2005 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms
+ of
the GNU General Public License.  This program has absolutely no warran
+ty.
This assembler was configured for a target of `mingw32'.
[download]

I think I'm on a different page :-)

I have a number of perls (some 32-bit, some 64-bit) all of which use the same (32-bit) dmake.
I have no problems with that, except for when it comes to building Win32::API.

For all other modules, it works fine.
With the 32-bit perls, running perl Makefile.PL generates a Makefile that specifies:
AR = ar.exe
CC = gcc.exe
That is correct, and as it should be.

With the 64-bit perls (which, obviously, use a different compiler), running perl Makefile.PL generates a Makefile that specifies:
AR = x86_64-w64-mingw32-ar.exe
CC = x86_64-w64-mingw32-gcc.exe
That is correct, and as it should be.

However, when building Win32::API, the assembler (as.exe) gets invoked.
No problem on the 32-bit perls - the assembler gets correctly invoked as 'as.exe'.
But on the 64-bit perls, it also gets invoked as 'as.exe' - which is incorrect as it ought to be invoked as 'x86_64-w64-mingw32-as.exe'.

Obviously there's some process somewhere that handles the correct setting of AR.
I would like to apply that same process to AS so that it, too, gets set correctly for the 64-bit perls.
But I don't know what/where that "process" actually is.
Any ideas ?

UPDATE: Seems that "ar", like "cc", is set in %Config.
But there is no %Config setting for "as" ... so I think I'm probably faced with hacking the dmake files (or copying 'x86_64-w64-mingw32-as.exe' to 'as.exe').
Ought there be a %Config setting for the assembler ?

Cheers,
Rob

Ought there be a %Config setting for the assembler ?

You decide.

You've described an excellent case for it being so.

And you are the only one who comes around here that has: the vaguest inclining of how this stuff works; and the tuits to make it happen.

Decide, and go tuit. Or not as you see fit. You have as much expertise and far more tuits on this subject than anyone else who still visits this place on a regular basis.

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

Ought there be a %Config setting for the assembler ?

Hmm, perl doesn't use it, so I guess not :/ maybe :)

If you look at Win32-API-0.77\Makefile.PL you'll see it uses $(AS) but it doesn't define it , which probably means it simply defaults to 'as'

You can always arrange for  perl Makefile.PL AS=x86_64-w64-mingw32-as.exe

dmake should also pick it up from %ENV via set AS=x86_64-w64-mingw32-as.exe or via sitecustomize $ENV{AS}='x86_64-w64-mingw32-as.exe';

Or give it to Makefile.PL via $ENV{PERL_MM_OPT} https://metacpan.org/pod/ExtUtils::MakeMaker#PERL_MM_OPT

So no Makefile hacking required, set some %ENV vars as usual :)

I guess whomever built your toolchain chose x86_64-w64-mingw32-as.exe so they can dump all the .exe in the same directory :) choices complicate choices :)

EU::MM would actually be getting the "as" value from Config_heavy.pl if "as" would exist in the future

Would EU::MM pick that up automatically ?
It's easy enough to set 'as' to the correct value ('x86_64-w64-mingw32-as') in Config_heavy.pl, and doing so means that $Config{as} is set to that correct value. However, $(AS) in the Win32::API Makefile is still set to the incorrect value of 'as'.
Perhaps it just needs 'as' to have been available (in config.gc) when perl was being built ... I haven't tested that out yet.

In any case, you're correct that the first thing to do is to get 'as' into the next release. I'll request that of p5p soon.

Cheers,
Rob