Thread: [Module::Build] Does ./Build work on Windows?
Status: Beta
Brought to you by:
kwilliams
Menu
▾
▴
module-build-general
|
From: <and...@fr...> - 2006-01-29 05:00:11
|
I got a bugreport for CPAN.pm that claims that ./Build does not work on Windows. If this is true, the whole support for Module::Build in CPAN.pm is broken. Please advise. -- andreas |
|
From: Chris D. <ch...@cl...> - 2006-01-29 05:14:39
|
On Jan 28, 2006, at 11:00 PM, Andreas J. Koenig wrote: > I got a bugreport for CPAN.pm that claims that ./Build does not work > on Windows. If this is true, the whole support for Module::Build in > CPAN.pm is broken. > > Please advise. It should be "perl Build" (for appropriate values of "perl") instead of ./Build. Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/) |
|
From: <and...@fr...> - 2006-01-29 08:19:34
|
>>>>> On Sat, 28 Jan 2006 23:13:25 -0600, Chris Dolan <ch...@cl...> said: > On Jan 28, 2006, at 11:00 PM, Andreas J. Koenig wrote: >> I got a bugreport for CPAN.pm that claims that ./Build does not work >> on Windows. If this is true, the whole support for Module::Build in >> CPAN.pm is broken. >> >> Please advise. > It should be "perl Build" (for appropriate values of "perl") instead > of ./Build. Is this really everything Module::Build has to offer? No Build.bat file? Has Build.bat been ever considered? It makes support from CPAN.pm's view a bit tricky (though not impossible), because we want a user-configurable call for the 'Build install' command and if that call involves the "appropriate value for perl", then the user needs a way to specify where the "appropriate value for perl" shall be included. -- andreas |
|
From: David G. <da...@hy...> - 2006-01-29 13:45:29
|
Andreas J. Koenig wrote: > Is this really everything Module::Build has to offer? No Build.bat > file? Has Build.bat been ever considered? > > It makes support from CPAN.pm's view a bit tricky (though not > impossible), because we want a user-configurable call for the 'Build > install' command and if that call involves the "appropriate value for > perl", then the user needs a way to specify where the "appropriate > value for perl" shall be included. I think you need to explain more about what the sticking point is. The "obvious" thing that jumps out is why not use $^X or a user-supplied alternative path to Perl? (E.g. "sudo /usr/bin/perl" -- but that's irrelevant for Windows-land anyway.) What's the use-case you're trying to support? Regards, David |
|
From: David G. <da...@hy...> - 2006-01-29 23:14:39
|
Andreas J. Koenig wrote: > > (2) Module::Build's mantra on Unix was easy: > > (/path/to)perl Build.PL > ./Build > ./Build test > ./Build install > > Only the first step had to decide which perl to use, the following > steps did not have to remember. > > (3) Module::Build's mantra on Windows is DIFFERENT: > > (/path/to)perl Build.PL > (/path/to)perl Build > (/path/to)perl Build test > (/path/to)perl Build install > > This is an unfortunate aberration. Somebody seems to have to remember > the /path/to part throughout the three steps. It's not an aberration -- it's an alternative, or technically a shortcut. If CPAN.pm is doing the calls, why not use /path/to/perl for all four when doing a Build.PL installation? (And do it with the $^X that called CPAN.pm unless a specifically different perl path is requested?) > What happens if I have two different perls installed on my Windows > system and I mix up the path in my three calls? > > Was it ever considered to generate a ./Build.bat file on Windows > systems, so that > > ./Build My 2 cents on this is that Module::Build's philosophy is to try to be perl-centric rather than OS-centric. If you can run perl, you can run Module::Build. All CPAN has to do is pick a perl to use and be consistent with that. All a .bat file would be is a wrapper around calling "perl Build" anyway, so why not do it explicitly and save the trouble. > > What's the use-case you're trying to support? > > CPAN.pm is a module that is used to download, make, and install > modules from the CPAN. It has only recently started to support > Module::Build but the author has no windows system and so did not > notice that the Windows support needs different treatment from the > Unix support. > > Before I do introduce a different code path for Windows in this area, > I'd like to hear from the Module::Build community if the above > described aberration is considered an ideal solution, a necessary > evil, or a bug. > > *My* wish would be that Windows would not need a special treatment. My recommendation is to have a separate code path for Module::Build and to *always* call Build.PL and Build with an explicit perl executable on all platforms. That should be platform independent. Regards, David |
|
From: <and...@fr...> - 2006-01-30 00:14:00
|
>>>>> On Sun, 29 Jan 2006 18:14:27 -0500, David Golden <da...@hy...> said: > Andreas J. Koenig wrote: >> (2) Module::Build's mantra on Unix was easy: >> (/path/to)perl Build.PL >> ./Build >> ./Build test >> ./Build install >> Only the first step had to decide which perl to use, the following >> steps did not have to remember. >> (3) Module::Build's mantra on Windows is DIFFERENT: >> (/path/to)perl Build.PL >> (/path/to)perl Build >> (/path/to)perl Build test >> (/path/to)perl Build install >> This is an unfortunate aberration. Somebody seems to have to remember >> the /path/to part throughout the three steps. > It's not an aberration -- it's an alternative, or technically a > shortcut. If CPAN.pm is doing the calls, why not use /path/to/perl for > all four when doing a Build.PL installation? (And do it with the $^X > that called CPAN.pm unless a specifically different perl path is > requested?) Because it simply is not very perlish to abandon shortcuts. -- andreas |
|
From: David G. <da...@hy...> - 2006-01-30 01:35:26
|
Andreas J. Koenig wrote: > > It's not an aberration -- it's an alternative, or technically a > > shortcut. If CPAN.pm is doing the calls, why not use /path/to/perl for > > all four when doing a Build.PL installation? (And do it with the $^X > > that called CPAN.pm unless a specifically different perl path is > > requested?) > > Because it simply is not very perlish to abandon shortcuts. That sounds like an excuse. You want CPAN.pm to call perl on Build.PL and for Build.PL to write a Build and Build.bat. That just means that Module::Build will be responsible for figuring out the right perl executable and sticking it in the .bat file. Is that really any different than having CPAN.pm just use the same perl executable all the way through? CPAN.pm still has to know which perl to call for Build.PL and it still has to call "./Build" three times. All you save is sticking the same perl *that you already have* (that ran Build.PL) in front of "./Build" each time. For that savings, you want Module::Build to create a Build.bat on windows? David |
|
From: Yitzchak Scott-T. <sth...@ef...> - 2006-01-30 09:19:14
|
On Sun, Jan 29, 2006 at 08:35:11PM -0500, David Golden wrote: > Andreas J. Koenig wrote: > > > > It's not an aberration -- it's an alternative, or technically a > > > shortcut. If CPAN.pm is doing the calls, why not use /path/to/perl for > > > all four when doing a Build.PL installation? (And do it with the $^X > > > that called CPAN.pm unless a specifically different perl path is > > > requested?) > > > >Because it simply is not very perlish to abandon shortcuts. > > That sounds like an excuse. You want CPAN.pm to call perl on Build.PL > and for Build.PL to write a Build and Build.bat. That just means that > Module::Build will be responsible for figuring out the right perl > executable and sticking it in the .bat file. Is that really any > different than having CPAN.pm just use the same perl executable all the > way through? CPAN.pm still has to know which perl to call for Build.PL > and it still has to call "./Build" three times. All you save is > sticking the same perl *that you already have* (that ran Build.PL) in > front of "./Build" each time. For that savings, you want Module::Build > to create a Build.bat on windows? Having a different perl run Build.PL vs. Build is almost certainly a user error; I'm pretty sure M::B already checks and warns if that happens. A Build.bat just makes M::B present to the windows user the same as a unix user and helps eliminate the possibility of user error. 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. |
|
From: <and...@fr...> - 2006-01-30 10:54:04
|
>>>>> 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! -- andreas |
|
From: Ken W. <ke...@ma...> - 2006-01-30 20:06:14
|
On Jan 30, 2006, at 4:53 AM, Andreas J. Koenig wrote: > 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! Hi Andreas, I haven't been pulling my weight in testing the CPAN.pm releases (I have no great Windows box to test it on, but I could at least do Unix testing). Should it be generally sufficient to run the regression tests, or would someone need to install it and play with it for a while too? -Ken |
|
From: <and...@fr...> - 2006-01-30 21:11:41
|
>>>>> On Mon, 30 Jan 2006 14:05:45 -0600, Ken Williams <ke...@ma...> said: > On Jan 30, 2006, at 4:53 AM, Andreas J. Koenig wrote: >> 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! > Hi Andreas, > I haven't been pulling my weight in testing the CPAN.pm releases (I > have no great Windows box to test it on, but I could at least do Unix > testing). Should it be generally sufficient to run the regression > tests, or would someone need to install it and play with it for a > while too? The latter, please. My regression tests are just an alibi. -- andreas |
|
From: Ron S. <ro...@sa...> - 2006-01-30 22:46:39
|
On Mon, 30 Jan 2006 22:10:34 +0100, Andreas J. Koenig wrote: Hi Andreas > The latter, please. My regression tests are just an alibi. Et tu, Brutus? I don't feel so bad 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: Ken W. <ke...@ma...> - 2006-01-30 22:54:30
|
On Jan 30, 2006, at 3:10 PM, Andreas J. Koenig wrote:
>>>>>> On Mon, 30 Jan 2006 14:05:45 -0600, Ken Williams
>>>>>> <ke...@ma...> said:
>
>> I haven't been pulling my weight in testing the CPAN.pm releases (I
>> have no great Windows box to test it on, but I could at least do Unix
>> testing). Should it be generally sufficient to run the regression
>> tests, or would someone need to install it and play with it for a
>> while too?
>
> The latter, please. My regression tests are just an alibi.
I just pulled down 1.83_59 and installed it, and I recommend the
following patch:
===========================================
--- Makefile.PL~ Wed Jan 25 06:05:22 2006
+++ Makefile.PL Mon Jan 30 16:49:59 2006
@@ -134,12 +134,6 @@
package MY;
-sub macro {
- q{
-LC_ALL=en_GB.utf8
-}
-}
-
sub postamble {
q{
setversion:
===========================================
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.
-Ken
|
|
From: <and...@fr...> - 2006-01-30 23:35:55
|
>>>>> On Mon, 30 Jan 2006 16:54:08 -0600, Ken Williams <ke...@ma...> said:
> On Jan 30, 2006, at 3:10 PM, Andreas J. Koenig wrote:
>>>>>>> On Mon, 30 Jan 2006 14:05:45 -0600, Ken Williams
>>>>>>> <ke...@ma...> said:
>>
>>> I haven't been pulling my weight in testing the CPAN.pm releases (I
>>> have no great Windows box to test it on, but I could at least do Unix
>>> testing). Should it be generally sufficient to run the regression
>>> tests, or would someone need to install it and play with it for a
>>> while too?
>>
>> The latter, please. My regression tests are just an alibi.
> I just pulled down 1.83_59 and installed it, and I recommend the
> following patch:
> ===========================================
> --- Makefile.PL~ Wed Jan 25 06:05:22 2006
> +++ Makefile.PL Mon Jan 30 16:49:59 2006
> @@ -134,12 +134,6 @@
> package MY;
> -sub macro {
> - q{
> -LC_ALL=en_GB.utf8
> -}
> -}
> -
> sub postamble {
> q{
> setversion:
> ===========================================
> 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.
'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?
What if you rename the macro like in this pseudo patch?
-LC_ALL=en_GB.utf8
+LC_ALL_XXX=en_GB.utf8
--
andreas
|
|
From: Ken W. <ke...@ma...> - 2006-01-30 20:04:49
|
On Jan 30, 2006, at 3:18 AM, Yitzchak Scott-Thoennes wrote: > Having a different perl run Build.PL vs. Build is almost certainly > a user error; I'm pretty sure M::B already checks and warns if that > happens. Right. > 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. Or maybe CPAN.pm will only support M::B >= 0.28, if 0.28 starts creating a Build.bat file. That's Andreas' call (subject to user pressure =). -Ken |
|
From: Ken W. <ke...@ma...> - 2006-01-30 23:01:56
|
Hi guys,
I'm happy to do it either way. The only advantage I can see on the
M::B side to writing Build.bat is that we could instruct users to type
the same incantation on Unix as they do on Win32: "perl Build.PL;
./Build; ./Build test; ./Build install". Various sticklers for
correctness got all over me in previous M::B releases because the
incantation I was using in the docs ("perl Build.PL; Build; Build test;
Build install") didn't work on windows.
Other than that, I think a Build.bat would be a nice convenience if it
doesn't introduce headaches. I'll have a look at Yves' patch at some
point.
-Ken
On Jan 29, 2006, at 7:35 PM, David Golden wrote:
> That sounds like an excuse. You want CPAN.pm to call perl on Build.PL
> and for Build.PL to write a Build and Build.bat. That just means that
> Module::Build will be responsible for figuring out the right perl
> executable and sticking it in the .bat file. Is that really any
> different than having CPAN.pm just use the same perl executable all
> the way through? CPAN.pm still has to know which perl to call for
> Build.PL and it still has to call "./Build" three times. All you save
> is sticking the same perl *that you already have* (that ran Build.PL)
> in front of "./Build" each time. For that savings, you want
> Module::Build to create a Build.bat on windows?
|
|
From: Ken W. <ke...@ma...> - 2006-01-29 23:27:30
|
On Jan 29, 2006, at 2:19 AM, Andreas J. Koenig wrote: >>>>>> On Sat, 28 Jan 2006 23:13:25 -0600, Chris Dolan >>>>>> <ch...@cl...> said: > >> On Jan 28, 2006, at 11:00 PM, Andreas J. Koenig wrote: >>> I got a bugreport for CPAN.pm that claims that ./Build does not work >>> on Windows. If this is true, the whole support for Module::Build in >>> CPAN.pm is broken. >>> >>> Please advise. > >> It should be "perl Build" (for appropriate values of "perl") instead >> of ./Build. > > Is this really everything Module::Build has to offer? No Build.bat > file? Has Build.bat been ever considered? We already do the script->.bat conversion for scripts that get installed, I think we could figure out an appropriate way to do the same for the Build script too. -Ken |
|
From: <and...@fr...> - 2006-01-29 23:58:22
|
>>>>> On Sun, 29 Jan 2006 17:27:21 -0600, Ken Williams <ke...@ma...> said: > On Jan 29, 2006, at 2:19 AM, Andreas J. Koenig wrote: >>>>>>> On Sat, 28 Jan 2006 23:13:25 -0600, Chris Dolan >>>>>>> <ch...@cl...> said: >> >>> On Jan 28, 2006, at 11:00 PM, Andreas J. Koenig wrote: >>>> I got a bugreport for CPAN.pm that claims that ./Build does not work >>>> on Windows. If this is true, the whole support for Module::Build in >>>> CPAN.pm is broken. >>>> >>>> Please advise. >> >>> It should be "perl Build" (for appropriate values of "perl") instead >>> of ./Build. >> >> Is this really everything Module::Build has to offer? No Build.bat >> file? Has Build.bat been ever considered? > We already do the script->.bat conversion for scripts that get > installed, I think we could figure out an appropriate way to do the > same for the Build script too. Thanks! -- andreas |
|
From: Randy W. S. <ml...@th...> - 2006-01-30 03:47:47
|
Ken Williams wrote: > > On Jan 29, 2006, at 2:19 AM, Andreas J. Koenig wrote: > >>>>>>> On Sat, 28 Jan 2006 23:13:25 -0600, Chris Dolan >>>>>>> <ch...@cl...> said: >> >> >>> On Jan 28, 2006, at 11:00 PM, Andreas J. Koenig wrote: >>> >>>> I got a bugreport for CPAN.pm that claims that ./Build does not work >>>> on Windows. If this is true, the whole support for Module::Build in >>>> CPAN.pm is broken. >>>> >>>> Please advise. >> >> >>> It should be "perl Build" (for appropriate values of "perl") instead >>> of ./Build. >> >> >> Is this really everything Module::Build has to offer? No Build.bat >> file? Has Build.bat been ever considered? > > > We already do the script->.bat conversion for scripts that get > installed, I think we could figure out an appropriate way to do the same > for the Build script too. Actually, IIRC, I special cased it in the Windows code to convert everything but "Build". At the time I there were some problems having the generated Build.bat delete itself during "perl Build realclean". I think Yves found a solution to this (ref "Help with a Cwd.pm build error" thread on p5p). I haven't done well following up on any of this as I've been rather busy with first of year stuff, but I hope to start getting caught up this week. Randy. |
|
From: demerphq <dem...@gm...> - 2006-01-30 09:11:39
Attachments:
mb.patch
|
Whoops, accidental reply instead of reply-to-all... ---------- Forwarded message ---------- On 1/30/06, Randy W. Sims <ml...@th...> wrote: > Ken Williams wrote: > > > > On Jan 29, 2006, at 2:19 AM, Andreas J. Koenig wrote: > > > >>>>>>> On Sat, 28 Jan 2006 23:13:25 -0600, Chris Dolan > >>>>>>> <ch...@cl...> said: > >> > >> > >>> On Jan 28, 2006, at 11:00 PM, Andreas J. Koenig wrote: > >>> > >>>> I got a bugreport for CPAN.pm that claims that ./Build does not work > >>>> on Windows. If this is true, the whole support for Module::Build in > >>>> CPAN.pm is broken. > >>>> > >>>> Please advise. > >> > >> > >>> It should be "perl Build" (for appropriate values of "perl") instead > >>> of ./Build. > >> > >> > >> Is this really everything Module::Build has to offer? No Build.bat > >> file? Has Build.bat been ever considered? > > > > > > We already do the script->.bat conversion for scripts that get > > installed, I think we could figure out an appropriate way to do the sam= e > > for the Build script too. > > Actually, IIRC, I special cased it in the Windows code to convert > everything but "Build". At the time I there were some problems having > the generated Build.bat delete itself during "perl Build realclean". I > think Yves found a solution to this (ref "Help with a Cwd.pm build > error" thread on p5p). I haven't done well following up on any of this > as I've been rather busy with first of year stuff, but I hope to start > getting caught up this week. 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=3Ddebug -e "/just|another|perl|hacker/" |
|
From: Randy W. S. <ml...@th...> - 2006-02-02 01:22:30
Attachments:
patch
|
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.
I think we can simplify, and apply this to all platforms.
> 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.)
Yeah. They were cleaned up as part of blib, but you're right, it should
be mentioned explicitly here.
> 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
Ok.
> Im sorry i havent gotten further on this, i was distracted by other things.
No problem. You're work on this and on fixing the "Cwd won't install"
problem in EU::Install is very very much appreciated.
> 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.
This is the only issue holding me up. I'm going to do some experimenting
and research to see if that annoying message can be eliminated somehow.
Attached is a manually applied version of your patch against current
cvs. The only changes are applying the close(*DATA) on all OS, removing
the extraneous Build_FollowUp logic, and some line wraps.
Thanks,
Randy.
> 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/"
>
>
> ------------------------------------------------------------------------
>
> diff -wur Module-Build-0.27_04/lib/Module/Build/Base.pm \dev\cpan\Module-Build-0.27_04_patched/lib/Module/Build/Base.pm
> --- Module-Build-0.27_04/lib/Module/Build/Base.pm 2005-12-23 17:54:53.000000000 +0100
> +++ \dev\cpan\Module-Build-0.27_04_patched/lib/Module/Build/Base.pm 2006-01-24 19:58:28.148126600 +0100
> @@ -847,7 +847,8 @@
> sub read_config {
> my ($self) = @_;
>
> - my $file = $self->config_file('build_params');
> + my $file = $self->config_file('build_params')
> + or die "No build_params?";
> my $fh = IO::File->new($file) or die "Can't read '$file': $!";
> my $ref = eval do {local $/; <$fh>};
> die if $@;
> @@ -1158,8 +1159,14 @@
>
> my $build_package = $self->build_class;
>
> + my $closedata="";
> +
> my %q = map {$_, $self->$_()} qw(config_dir base_dir);
> - $q{base_dir} = Win32::GetShortPathName($q{base_dir}) if $^O eq 'MSWin32';
> + if ( $^O eq 'MSWin32' ) {
> + $q{base_dir} = Win32::GetShortPathName($q{base_dir});
> + $closedata="\nclose(*DATA) unless eof(*DATA);"
> + ."# Necessary on Win32 to allow realclean!\n";
> + }
> my $case_tolerant = 0+(File::Spec->can('case_tolerant')
> && File::Spec->case_tolerant);
> $q{base_dir} = uc $q{base_dir} if $case_tolerant;
> @@ -1180,7 +1187,7 @@
> use Cwd;
> use File::Basename;
> use File::Spec;
> -
> +$closedata
> my \$progname;
> my \$orig_dir;
> BEGIN {
> diff -wur Module-Build-0.27_04/lib/Module/Build/Platform/Windows.pm \dev\cpan\Module-Build-0.27_04_patched/lib/Module/Build/Platform/Windows.pm
> --- Module-Build-0.27_04/lib/Module/Build/Platform/Windows.pm 2005-12-23 17:54:53.000000000 +0100
> +++ \dev\cpan\Module-Build-0.27_04_patched/lib/Module/Build/Platform/Windows.pm 2006-01-24 19:57:05.382501600 +0100
> @@ -40,17 +40,26 @@
> my $pl2bat = $self->{config}{pl2bat};
>
> if ( defined($pl2bat) && length($pl2bat) ) {
> + my $ext= $ENV{PATHEXT}=~/\.CMD(\W|$)/i ? '.cmd' : '.bat';
> +
> foreach my $script (@_) {
> - # Don't run 'pl2bat.bat' for the 'Build' script;
> - # there is no easy way to get the resulting 'Build.bat'
> - # to delete itself when doing a 'Build realclean'.
> - next if ( $script eq $self->{properties}{build_script} );
>
> (my $script_bat = $script) =~ s/\.plx?//i;
> - $script_bat .= '.bat' unless $script_bat =~ /\.bat$/i;
> -
> + if ($script_bat =~ /\.(bat|cmd)$/i) {
> + warn "Won't convert '$script' to a batch file named '$script_bat' nor to '$script_bat$ext'.\n";
> + next;
> + }
> + $script_bat .= $ext;
> + $self->add_to_cleanup($script_bat);
> my $status = $self->do_system($pl2bat, '<', $script, '>', $script_bat);
> +
> if ( $status && -f $script_bat ) {
> + if ( $script eq $self->{properties}{build_script} ) {
> + open my $fh, ">>", $script_bat or
> + die "Failed to open for append batch file '$script':$!";
> + print $fh "\nif exist Build_FollowUp$ext Build_FollowUp$ext\n";
> + close $fh;
> + }
> $self->SUPER::make_executable($script_bat);
> } else {
> warn "Unable to convert '$script' to an executable.\n";
>
>
>
>
>
>
|
|
From: demerphq <dem...@gm...> - 2006-02-02 08:52:11
|
On 2/2/06, Randy W. Sims <ml...@th...> wrote:
> 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.
>
> I think we can simplify, and apply this to all platforms.
I think that this can be avoided for anything but clean like targets,
and for those targets it occured to me that it probably should happen
as late as possibe. I'm not sure if i read your patch correctly, maybe
it already does that but it thought it would be worth mentioning.
> > 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.)
>
> Yeah. They were cleaned up as part of blib, but you're right, it should
> be mentioned explicitly here.
Ok. Im glad i didnt miss it happening somewhere/somehow else. :-)
> > 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
>
> Ok.
Sigh. I'm now wondering about the wisdom of this. Other tools may be
expecting '.bat' extensions and fail because of the change. I think
actually despite my other feelings on it that a more conservative
approach is called for and this change should be reversed until we can
find proof that there is a good reason for it (my hazy recollections
dont count). Maybe it could be made optional somehow. But ill leave
that decision to you.
Sorry to waste your time with it.
> > Im sorry i havent gotten further on this, i was distracted by other thi=
ngs.
>
> No problem. You're work on this and on fixing the "Cwd won't install"
> problem in EU::Install is very very much appreciated.
>
> > 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.
>
> This is the only issue holding me up. I'm going to do some experimenting
> and research to see if that annoying message can be eliminated somehow.
Yeah. Its an interesting question. Ill look into it too.
> Attached is a manually applied version of your patch against current
> cvs. The only changes are applying the close(*DATA) on all OS, removing
> the extraneous Build_FollowUp logic, and some line wraps.
Ill have a go applying it later. Thanks.
yves
> Index: lib/Module/Build/Base.pm
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> RCS file: /cvsroot/module-build/Module-Build/lib/Module/Build/Base.pm,v
> retrieving revision 1.544
> diff -u -r1.544 Base.pm
> --- lib/Module/Build/Base.pm 23 Jan 2006 13:27:43 -0000 1.544
> +++ lib/Module/Build/Base.pm 2 Feb 2006 00:54:22 -0000
> @@ -1188,6 +1188,9 @@
> use File::Basename;
> use File::Spec;
>
> +close(*DATA) unless eof(*DATA); # must close before unlinking ourself
> + # necessary on MSWin32 for realclean a=
ction
> +
> sub magic_number_matches {
> return 0 unless -e '$q{magic_numfile}';
> local *FH;
> @@ -1257,6 +1260,7 @@
> $self->print_build_script($fh);
> close $fh;
>
> + local $self->{properties}{quiet} =3D 1;
> $self->make_executable($build_script);
>
> return 1;
> Index: lib/Module/Build/Platform/Windows.pm
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> RCS file: /cvsroot/module-build/Module-Build/lib/Module/Build/Platform/Wi=
ndows.pm,v
> retrieving revision 1.26
> diff -u -r1.26 Windows.pm
> --- lib/Module/Build/Platform/Windows.pm 21 Jan 2006 18:05:01 -000=
0 1.26
> +++ lib/Module/Build/Platform/Windows.pm 2 Feb 2006 00:54:22 -0000
> @@ -56,16 +56,20 @@
> my $pl2bat =3D $self->{config}{pl2bat};
>
> if ( defined($pl2bat) && length($pl2bat) ) {
> - foreach my $script (@_) {
> - # Don't run 'pl2bat.bat' for the 'Build' script;
> - # there is no easy way to get the resulting 'Build.bat'
> - # to delete itself when doing a 'Build realclean'.
> - next if ( $script eq $self->{properties}{build_script} );
> + my $ext =3D ( $ENV{PATHEXT}=3D~/\.CMD(\W|$)/i )
> + ? '.cmd' : '.bat';
>
> + foreach my $script (@_) {
> (my $script_bat =3D $script) =3D~ s/\.plx?//i;
> - $script_bat .=3D '.bat' unless $script_bat =3D~ /\.bat$/i;
>
> - my $status =3D $self->do_system("$self->{properties}{perl} $pl2bat=
< $script > $script_bat");
> + # already has executable extension
> + next if ($script_bat =3D~ /\.(bat|cmd)$/i);
> +
> + $script_bat .=3D $ext;
> + $self->add_to_cleanup($script_bat);
> +
> + my $status =3D $self->do_system(
> + "$self->{properties}{perl} $pl2bat < $script > $script_bat" );
> if ( $status && -f $script_bat ) {
> $self->SUPER::make_executable($script_bat);
> } else {
>
>
>
--
perl -Mre=3Ddebug -e "/just|another|perl|hacker/"
|
|
From: Randy W. S. <Ra...@Th...> - 2006-02-21 03:04:43
|
demerphq wrote: > On 2/2/06, Randy W. Sims <ml...@th...> wrote: >>> 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. >> This is the only issue holding me up. I'm going to do some experimenting >> and research to see if that annoying message can be eliminated somehow. > > Yeah. Its an interesting question. Ill look into it too. I think this is now solved in CVS thanks to help from folks over on alt.msdos.batch. It should work on all NT variants, hopefully 9x also, but that hasn't been tested-I don't have access to anything that old. Anyone willing to test can grab the latest from cvs or I've got a snapshot at: <http://thepierianspring.org/perl/Module-Build.tar.gz> Thanks, Randy. |
|
From: Ron S. <ro...@sa...> - 2006-02-21 08:44:35
|
On Mon, 20 Feb 2006 22:04:47 -0500, Randy W. Sims wrote: Hi Randy Win2K here. Looks good. > <http://thepierianspring.org/perl/Module-Build.tar.gz> (1) I hope this is irrelevant: C:\Temp\Module-Build>perl Build.PL Checking whether your kit is complete... WARNING: the following files are missing in your kit: t/bundled/Test/Builder.pm t/bundled/Test/More.pm t/bundled/Test/Simple.pm (2) perl Build test gives: C:\Temp\Module-Build>perl Build test t\basic...........ok t\compat..........ok t\destinations....ok 8/92 skipped: various reasons t\ext.............ok t\extend..........ok t\files...........ok t\install.........ok t\manifypods......ok t\metadata........ok t\metadata2.......ok t\moduleinfo......ok t\notes...........ok t\parents.........ok t\pod_parser......ok t\ppm.............skipped all skipped: C_support not enabled t\runthrough......ok t\signature.......skipped all skipped: $ENV{TEST_SIGNATURE} is not set t\tilde...........ok t\versions........ok t\xs..............skipped all skipped: C_support not enabled All tests successful, 3 tests and 8 subtests skipped. Files=3D20, Tests=3D626, 64 wallclock secs ( 0.00 cusr + 0.00 csys =3D 0.00= CPU) -- Cheers Ron Savage, ro...@sa... on 21/02/2006 http://savage.net.au/index.html Let the record show: Microsoft is not an Australian company |
|
From: Ken W. <ke...@ma...> - 2006-02-27 02:08:16
|
On Feb 20, 2006, at 9:04 PM, Randy W. Sims wrote: > demerphq wrote: >> On 2/2/06, Randy W. Sims <ml...@th...> wrote: >>>> 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. >>> This is the only issue holding me up. I'm going to do some >>> experimenting >>> and research to see if that annoying message can be eliminated >>> somehow. >> Yeah. Its an interesting question. Ill look into it too. > > I think this is now solved in CVS thanks to help from folks over on > alt.msdos.batch. It should work on all NT variants, hopefully 9x > also, but that hasn't been tested-I don't have access to anything > that old. Anyone willing to test can grab the latest from cvs or > I've got a snapshot at: Excellent. Should we change the docs (e.g. synopsis in Build.pm and the first recipe in the cookbook) now to recommend doing "Build foo" instead of "perl Build foo" on Windows? -Ken |
Thanks for helping keep SourceForge clean.
X