RE: Build 1006 has some unexpected Config values
On Thu, 03 Sep 2009, Sisyphus wrote:
With build 1006, I'm getting the following:
#
C:\_32perl -V:cc
Set up gcc environment - 3.4.5 (mingw-vista special r3)
cc='C:/_32/ap1005/site/bin/gcc.exe';
C:\_32perl -V:ld
Set up gcc environment - 3.4.5 (mingw-vista special r3)
ld='C:\_32\ap1005\site\bin\g++.exe';
C:\_32perl -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
Re: Build 1006 has some unexpected Config values
- Original Message -
From: Jan Dubois j...@activestate.com
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.
That's what I was wondering. If it's not prohibited, then it's permitted :-)
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.
Would you mind filing a bug report for it?
Shall do - along with a patch.
ExtUtils::MM_Win32 uses this mechanism:
sub is_make_type {
my($self, $type) = @_;
return !! ($self-make =~ /\b$type(?:\.exe)?$/);
}
I'll probably just do
if($Config{make} =~ /\bdmake/i) { ... }
(I think it's only 5 files in PDL that need the amendment.)
Thanks Jan.
Cheers,
Rob
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: Build 1006 has some unexpected Config values
On Thu, 03 Sep 2009, Sisyphus wrote:
From: Jan Dubois j...@activestate.com
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.
That's what I was wondering. If it's not prohibited, then it's permitted :-)
Well there you go then! :)
As a further datapoint, $Config::Config{ar} on 64-bit AIX contains not
just the commandname ar but even additional flags ar -X64.
Of course that is quite a dangerous precedent, as it means we couldn't
really store pathnames with spaces in these %Config entries because
applications would know if the individual words would be part of a
single long pathname, or if they represented options to the command. :(
Cheers,
-Jan
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
