On Thu, 03 Sep 2009, Sisyphus wrote:
> With build 1006, I'm getting the following:
>
> #################################
> C:\_32>perl -V:cc
> Set up gcc environment - 3.4.5 (mingw-vista special r3)
> cc='C:/_32/ap1005/site/bin/gcc.exe';
>
> C:\_32>perl -V:ld
> Set up gcc environment - 3.4.5 (mingw-vista special r3)
> ld='C:\_32\ap1005\site\bin\g++.exe';
>
> C:\_32>perl -V:make
> make='C:\_32\ap1005\site\bin\dmake.exe';
>
> C:\_32>
> #################################
This is an intentional change. It enables the dmake/MinGW suppot even for
users that manually setup the PATH to include Perl\bin but forget to include
the Perl\site\bin directory as well.
> Is it acceptable to have those Config values specify the full path and
> extension ?
Acceptable by whom? :) The documentation doesn't really say one way or the
other:
| cc (cc.U):
| This variable holds the name of a command to execute a C compiler which
| can resolve multiple global references that happen to have the same
| name. Usual values are 'cc' and 'gcc'.
| Fervent ANSI compilers may be called 'c89'. AIX has xlc.
So it is customary to have a plain name, but it doesn't say that you can't
have the full name (including the file extension).
I did have to fix some tests inside ExtUtils::* module to deal with this
correctly, so I should better get on with getting those changes into
the next ExtUtils::MakeMaker release as well...
> This prevents Inline::C from building as C:/_32/ap1005/site/bin/gcc.exe.exe
> (which, of course, doesn't exist) can't be found by the C/Makefile.PL. And
I'll argue that that is a bug in Inline::C. The first GCC on the PATH could
be a gcc.bat wrapper, and Inline::C would then miss that one as well.
Would you mind filing a bug report for it?
> I'm sure I've written the odd Makefile.PL or two where I've done something
> like:
>
> if($Config{make} eq 'dmake') {
> # do something
> }
>
> That will now have to be rewritten as:
>
> if($Config{make} =~ /dmake/) {
> # do something
> }
ExtUtils::MM_Win32 uses this mechanism:
sub is_make_type {
my($self, $type) = @_;
return !! ($self->make =~ /\b$type(?:\.exe)?$/);
}
I could make a (weak) argument that in addition to .exe it should also
allow .bat, .cmd, and .com, but I'm not aware of anyone using non-.exe
wrappers for nmake/dmake.
Cheers,
-Jan
_______________________________________________
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
