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