Thread: Re: [Module::Build] Does ./Build work on Windows? (Page 2)
Status: Beta
Brought to you by:
kwilliams
Menu
▾
▴
module-build-general
|
From: Ken W. <ke...@ma...> - 2006-02-16 04:30:49
|
Okay, I'm about to commit this patch. I had some trouble applying it because there seemed to have been some whitespace differences, not that I could actually find them, so I applied by hand. You might want to look at it after I applied to make sure it works properly. -Ken On Jan 30, 2006, at 3:11 AM, demerphq wrote: > The change required to MB to handle this is minimal and is implemented > in a provisional form in the attached patch. > > When the Build script is created it needs to add the line > > close *DATA unless eof(*DATA); > > when being used on win32. Then the exception line in pl2script needs > to be removed. > > Additionally when scripts are pl2bat'ed their bat names need to be > added to the cleanup list. This currently doesnt happen at all so MB > cant/doesnt clean up pl2batted files properly. (It may do so > indirectly as a directory cleanup but this doesnt help the build > script itself.) > > Also, my preference (and i think the preference of many in the windows > world) is to avoid ".bat" files on NT and latter Win32 OS'es. It > should use the .cmd extension when on NT, W2K and XP or later. I > hazzily recall there is a good reason for this, but i have to admit I > dont remember what it is. Maybe its just cargo cultism and doesnt > matter at all. Anyway, the point is the attached patch includes such > logic. :-) I based it the behaviour change on the presence of .CMD in > the PATHEXT enviornment var so on machines without either it will > default to .bat > > Im sorry i havent gotten further on this, i was distracted by other > things. > > BTW, there is one annoying thing about self deletion of the .cmd/.bat > Build file. When control returns to the shell it raises a warning > about the batch file unexpected ending. Its not an issue, but it is > inelegant so figuring out how to make it go away would be nice. > > Er, also, it might be worth just replacing the pl2bat behaviour with > the creation of a generic Build.cmd that just contained the logic to > launch perl Build. Then it wouldnt need to be cleaned up, and avoid > the other little issues involved. > > Cheers, > yves > > -- > perl -Mre=debug -e "/just|another|perl|hacker/" > <mb.patch> |
|
From: <and...@fr...> - 2006-01-30 22:16:39
|
(CC shortened) >>>>> On Mon, 30 Jan 2006 15:25:48 -0600 (CST), Randy Kobes <ra...@th...> said: >> file: $CPAN/authors/id/A/AN/ANDK/CPAN-1.83_60.tar.gz >> size: 188821 bytes >> md5: 6b93c7048ae867c25b90aa0dab215324 >> >> I'd be grateful if some Windows users on this list could test this >> release a little. -- Thanks! > I installed this on a Win32 system (ActivePerl 815), together with > Module-Build-0.27_06, and set the preferences to favour using > Module::Build. Using the CPAN.pm shell to then install, for example, > DateTime::Locale, results in building and testing OK, but the install > fails, as it's using > ./Build install > for installing things. Interesting. Could you run 'o conf' and send me the output, then run 'o conf commit' once and then retry the install command? Thanks, -- andreas |
|
From: Randy K. <ra...@th...> - 2006-01-30 22:34:12
|
On Mon, 30 Jan 2006, Andreas J. Koenig wrote: > (CC shortened) > >>>>>> On Mon, 30 Jan 2006 15:25:48 -0600 (CST), Randy Kobes <ra...@th...> said: > > >> file: $CPAN/authors/id/A/AN/ANDK/CPAN-1.83_60.tar.gz > >> size: 188821 bytes > >> md5: 6b93c7048ae867c25b90aa0dab215324 > >> > >> I'd be grateful if some Windows users on this list could test this > >> release a little. -- Thanks! > > > I installed this on a Win32 system (ActivePerl 815), together with > > Module-Build-0.27_06, and set the preferences to favour using > > Module::Build. Using the CPAN.pm shell to then install, for example, > > DateTime::Locale, results in building and testing OK, but the install > > fails, as it's using > > ./Build install > > for installing things. > > Interesting. Could you run 'o conf' and send me the output, then run > 'o conf commit' once and then retry the install command? Thanks for the pointer - I think the problem is the following. I had installed 1.83_59 before, and in there there was defined a 'mbuild_install_build_command' in $CPAN::Config, with value q[./Build]. In upgrading to 1.83_60, this key still exists in the old $CPAN::Config, so "./Build install" is still used as the install command. Reconfiguring the CPAN.pm shell manually so that the mbuild_install_build_command key is removed (on Win32) then results in a successful build and install. So I suppose on Win32 the change needed is to reconfigure things when the CPAN.pm shell is first invoked after upgrading, so that this key gets removed. -- best regards, Randy |
|
From: David G. <da...@hy...> - 2006-01-30 20:55:57
|
CPAN.pm 1.83_59 does this to set up to run Build.PL:
my($perl) = $self->perl or die "Couldn\'t find executable perl\n";
$system = "$perl Build.PL $CPAN::Config->{mbuildpl_arg}";
Then it does this to set up the subsequent call to it:
$system = "./Build $CPAN::Config->{mbuild_arg}";
$system = "./Build test";
$system = "./Build clean";
Every single one of these could be replaced with something like the first:
$system = "$perl ./Build $CPAN::Config->{mbuild_arg}";
$system = "$perl ./Build test";
$system = "$perl ./Build clean";
That's a minute patch that should make CPAN.pm run ./Build on any system
that has Perl and can run Build.PL in the first place. I don't
understand why creating/destroying a .bat file is preferable. Am I
missing something?
Only install is more complex:
my($mbuild_install_build_command) =
$CPAN::Config->{'mbuild_install_build_command'} ||
"./Build";
$system = join(" ",
$mbuild_install_build_command,
"install",
$CPAN::Config->{mbuild_install_arg},
);
Even that could be "$perl ./Build" -- and the docs could say that
mbuild_install_arg should be "sudo perl ./Build".
Unless I'm missing something, I'd really rather see a simple (and
backwards compatible) patch to CPAN.pm than another crufty, OS-specific
behavior added to Module::Build.
Regards,
David
|
|
From: <and...@fr...> - 2006-01-30 21:28:10
|
>>>>> On Mon, 30 Jan 2006 15:55:36 -0500, David Golden <da...@hy...> said:
> CPAN.pm 1.83_59 does this to set up to run Build.PL:
> my($perl) = $self->perl or die "Couldn\'t find executable perl\n";
> $system = "$perl Build.PL $CPAN::Config->{mbuildpl_arg}";
> Then it does this to set up the subsequent call to it:
> $system = "./Build $CPAN::Config->{mbuild_arg}";
> $system = "./Build test";
> $system = "./Build clean";
> Every single one of these could be replaced with something like the first:
> $system = "$perl ./Build $CPAN::Config->{mbuild_arg}";
> $system = "$perl ./Build test";
> $system = "$perl ./Build clean";
> That's a minute patch that should make CPAN.pm run ./Build on any
> system that has Perl and can run Build.PL in the first place.
David Golden, listen, the part of CPAN.pm is done in 1.83_60. Ticket
closed on the CPAN.pm side. I may have introduced bugs, and I hope I
will get feedback to fix them.
> I don't understand why creating/destroying a .bat file is
> preferable.
Because it is the *goal* of Module::Build to make life easier for the
users.
> Am I missing something?
I'd say the obvious.
> Only install is more complex:
> my($mbuild_install_build_command) =
> $CPAN::Config->{'mbuild_install_build_command'} ||
> "./Build";
> $system = join(" ",
> $mbuild_install_build_command,
> "install",
> $CPAN::Config->{mbuild_install_arg},
> );
> Even that could be "$perl ./Build" -- and the docs could say that
> mbuild_install_arg should be "sudo perl ./Build".
> Unless I'm missing something, I'd really rather see a simple (and
> backwards compatible) patch to CPAN.pm than another crufty,
> OS-specific behavior added to Module::Build.
Oh yeah, you're apparently missing what kind of problem Module::Build
is trying to solve.
I suggest this thread to be closed now. I for one will not argue on
the matter any more.
Bugreports welcome, but please open new threads for them.
Thanks,
--
andreas
|
|
From: Ron S. <ro...@sa...> - 2006-01-30 22:53:35
|
On Mon, 30 Jan 2006 15:55:36 -0500, David Golden wrote: Hi David > Unless I'm missing something, I'd really rather see a simple (and > backwards compatible) patch to CPAN.pm than another crufty, OS- > specific behavior added to Module::Build. Just for the record, I'm missing it too. Please guys: Everybody take a cold shower and revisit this next week,= because you're talking at cross-purposes right now. -- Cheers Ron Savage, ro...@sa... on 31/01/2006 http://savage.net.au/index.html Let the record show: Microsoft is not an Australian company |
|
From: David G. <da...@hy...> - 2006-01-31 01:36:37
|
Ron Savage wrote: > On Mon, 30 Jan 2006 15:55:36 -0500, David Golden wrote: >>Unless I'm missing something, I'd really rather see a simple (and >>backwards compatible) patch to CPAN.pm than another crufty, OS- >>specific behavior added to Module::Build. > > Just for the record, I'm missing it too. > > Please guys: Everybody take a cold shower and revisit this next week, because > you're talking at cross-purposes right now. That's my bad. Andreas has already rolled that fix into the next release of CPAN.pm. The remainder of the discussion is now on whether Module::Build should create a .bat just because it makes life simpler for Windows users -- irrespective of the CPAN.pm issue. We've moved from CPAN.pm compatibility issue to M::B feature wish list. I promise to read the threads more closely next time. David |
|
From: Randy K. <ra...@th...> - 2006-01-30 21:27:57
|
On Mon, 30 Jan 2006, Andreas J. Koenig wrote:
>>>>>> On Mon, 30 Jan 2006 01:18:40 -0800, Yitzchak Scott-Thoennes <sth...@ef...> said:
>
> > But it seems to me CPAN is going to need to have windows-specific code
> > that Andreas wants to avoid anyway to support the existing versions of
> > Module::Build.
>
> Thanks for the reminder:)
>
> It's now in
>
> file: $CPAN/authors/id/A/AN/ANDK/CPAN-1.83_60.tar.gz
> size: 188821 bytes
> md5: 6b93c7048ae867c25b90aa0dab215324
>
> I'd be grateful if some Windows users on this list could test this
> release a little. -- Thanks!
I installed this on a Win32 system (ActivePerl 815),
together with Module-Build-0.27_06, and set the preferences
to favour using Module::Build. Using the CPAN.pm shell to
then install, for example, DateTime::Locale, results in
building and testing OK, but the install fails, as it's
using
./Build install
for installing things.
--
best regards,
Randy Kobes
|
|
From: Ken W. <ke...@ma...> - 2006-01-31 01:51:27
|
On Jan 30, 2006, at 5:33 PM, Andreas J. Koenig wrote:
>
>> The en_GB.utf8 locale isn't recognized on my platform (Mac OS X
>> 10.3.9) so I get a million warnings about it during the build & tests.
>
> This is completely incomprehensible to me. The LC_ALL macro is only
> used during 'make chlog' which you certainly have not called.
The problem is that there's an unholy incestuous relationship between
make variables and environment variables. Setting LC_ALL as a macro
sets it as an environment variable for all subprocesses too, whether
their actions use the macro or not:
----------------------------------------------------
[scotchie:/tmp] ken% cat Makefile
FOOENV=HiMom
LC_ALL=en_GB.utf8
testenv:
perl -le 'print "$$_: $$ENV{$$_}" for "FOOENV", "LC_ALL"'
[scotchie:/tmp] ken% make testenv
perl -le 'print "$_: $ENV{$_}" for "FOOENV", "LC_ALL"'
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LC_ALL = "en_GB.utf8",
LANG = (unset)
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
FOOENV:
LC_ALL: en_GB.utf8
[scotchie:/tmp] ken%
----------------------------------------------------
It only does this if the variable is already defined in the user's
shell:
----------------------------------------------------
[scotchie:/tmp] ken% unsetenv LC_ALL
[scotchie:/tmp] ken% make testenv
perl -le 'print "$_: $ENV{$_}" for "FOOENV", "LC_ALL"'
FOOENV:
LC_ALL:
----------------------------------------------------
(I just learned this last fact myself.)
>
> 'make', 'make test', and 'make install' should not be influenced by
> this macro. Is it so on OS X that macros are magically transposed into
> environment variables?
Not just on OS X, lots of platforms - OS X just uses the standard GNU
make, version 3.79 in my case. The GNU make manual says:
Except by explicit request, make exports a variable only if it is
either defined in the environment initially or set on the command
line,
and if its name consists only of letters, numbers, and underscores.
[http://www.gnu.org/software/make/manual/html_chapter/
make_5.html#SEC60]
For the record, I hate this behavior of make.
>
> What if you rename the macro like in this pseudo patch?
>
> -LC_ALL=en_GB.utf8
> +LC_ALL_XXX=en_GB.utf8
Yup, then I get no complaints at all.
-Ken
|
|
From: <and...@fr...> - 2006-01-31 07:14:52
|
(trimmed CC) >>>>> On Mon, 30 Jan 2006 19:51:19 -0600, Ken Williams <ke...@ma...> said: > On Jan 30, 2006, at 5:33 PM, Andreas J. Koenig wrote: >> >>> The en_GB.utf8 locale isn't recognized on my platform (Mac OS X >>> 10.3.9) so I get a million warnings about it during the build & tests. >> >> This is completely incomprehensible to me. The LC_ALL macro is only >> used during 'make chlog' which you certainly have not called. > The problem is that there's an unholy incestuous relationship between > make variables and environment variables. Setting LC_ALL as a macro > sets it as an environment variable for all subprocesses too, whether > their actions use the macro or not: > [...] Thanks for the edutainment:) > For the record, I hate this behavior of make. Then we are two:) >> >> What if you rename the macro like in this pseudo patch? >> >> -LC_ALL=en_GB.utf8 >> +LC_ALL_XXX=en_GB.utf8 > Yup, then I get no complaints at all. So this is fixed in my copy. Thanks! -- andreas |
Thanks for helping keep SourceForge clean.
X