module-build-general Mailing List for Module::Build (Page 22)
Status: Beta
Brought to you by:
kwilliams
Menu
▾
▴
module-build-general — General discussion about Module::Build project
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(24) |
Sep
(2) |
Oct
(18) |
Nov
(36) |
Dec
(17) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(3) |
Feb
(96) |
Mar
(82) |
Apr
(63) |
May
(90) |
Jun
(52) |
Jul
(94) |
Aug
(89) |
Sep
(75) |
Oct
(118) |
Nov
(101) |
Dec
(111) |
| 2004 |
Jan
(159) |
Feb
(155) |
Mar
(65) |
Apr
(121) |
May
(62) |
Jun
(68) |
Jul
(54) |
Aug
(45) |
Sep
(78) |
Oct
(80) |
Nov
(271) |
Dec
(205) |
| 2005 |
Jan
(128) |
Feb
(96) |
Mar
(83) |
Apr
(113) |
May
(46) |
Jun
(120) |
Jul
(146) |
Aug
(47) |
Sep
(93) |
Oct
(118) |
Nov
(116) |
Dec
(60) |
| 2006 |
Jan
(130) |
Feb
(330) |
Mar
(228) |
Apr
(203) |
May
(97) |
Jun
(15) |
Jul
(6) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Ken W. <ke...@ma...> - 2006-03-04 16:06:27
|
On Mar 4, 2006, at 9:36 AM, Andreas J. Koenig wrote: > One of the mysteries of CPAN.pm are return codes. Maybe we will get > them some day, but for the time being you have > $module->uptodate > to test for a module being up-to-date. Oh good, thanks. I'll see about adding that in. -Ken |
|
From: Ken W. <ke...@ma...> - 2006-03-04 16:05:18
|
On Mar 3, 2006, at 7:04 PM, Randy W. Sims wrote: > > After further cleanup and testing, I've checked in the changes with > doc tweaks. > Great. I've released the current snapshot (before adding the testpodcoverage action) as a new beta. Very Little To Do Before 0.28 Now. -Ken |
|
From: <and...@fr...> - 2006-03-04 15:36:15
|
>>>>> On Wed, 1 Mar 2006 21:42:21 -0600, Ken Williams <ke...@ma...> said:
> @@ -90,8 +90,8 @@
> # Save this 'cause CPAN will chdir all over the place.
> my $cwd = Cwd::cwd();
> - CPAN::Shell->install('Module::Build::Compat')
> - or die " *** Cannot install without Module::Build. Exiting ...\n";
> + # There seems to be no way to determine if this install was
> successful
> + CPAN::Shell->install('Module::Build::Compat');
> chdir $cwd or die "Cannot chdir() back to $cwd: $!";
> }
> I did this because I was on Cygwin installing a module that had a
> passthrough Makefile.PL, and I didn't have M::B already installed.
> It offered to use CPAN.pm to install M::B for me, which succeeded,
> and then it died with the above error message, because install()
> returned false even when it was successful.
> Inspecting the CPAN.pm code, I can't quite see *why* it returned
> false, but the docs don't say it returns any value in particular, so
> I thought I shouldn't rely on one. I think it might be the case that
> different versions of CPAN return different values, perhaps?
One of the mysteries of CPAN.pm are return codes. Maybe we will get
them some day, but for the time being you have
$module->uptodate
to test for a module being up-to-date.
--
andreas
|
|
From: Randy W. S. <ml...@th...> - 2006-03-04 01:04:17
|
Ken Williams wrote: > > On Mar 3, 2006, at 2:26 PM, Randy W. Sims wrote: > >> I got this mostly done last night: >> >> <http://thepierianspring.org/perl/Module-Build.tar.gz> >> >> I just need to review and test, hopefully getting one more round of >> tests from Win98 land. Also, I need to update the docs. >> >> It mostly duplicates pl2bat with some minor exceptions, but it also >> cleaned up M::B::P::Windows.pm a good bit: eliminated the constructor >> override, the _find_pl2bat() method, and greatly simplified the >> make_executable() method. It works for me. > > Yay! > >> >> I'll problably check it in sometime this evening, after docs & review; >> there is no variation in this area on Win98 anymore, so I don't expect >> failure there related to this issue. > > Cool. After further cleanup and testing, I've checked in the changes with doc tweaks. Randy. |
|
From: Ken W. <ke...@ma...> - 2006-03-03 22:13:45
|
On Mar 3, 2006, at 2:26 PM, Randy W. Sims wrote: > I got this mostly done last night: > > <http://thepierianspring.org/perl/Module-Build.tar.gz> > > I just need to review and test, hopefully getting one more round of > tests from Win98 land. Also, I need to update the docs. > > It mostly duplicates pl2bat with some minor exceptions, but it also > cleaned up M::B::P::Windows.pm a good bit: eliminated the > constructor override, the _find_pl2bat() method, and greatly > simplified the make_executable() method. It works for me. Yay! > > I'll problably check it in sometime this evening, after docs & > review; there is no variation in this area on Win98 anymore, so I > don't expect failure there related to this issue. Cool. -Ken |
|
From: David W. <da...@ki...> - 2006-03-03 21:44:13
|
On Feb 17, 2006, at 11:30, David Wheeler wrote:
>> I just discovered install-base_relpaths, and for setting up new
>> elements to simply be installed relative to whatever the
>> install_base happens to be, it's very convenient. I'd like to see
>> it documented in the cookbook. The attached patch adds a note
>> about it there. Think you might let this be documented?
>
> Or perhaps better still, add_build_element could make it the
> default? That patch would look like this:
>
> --- Base.pm 16 Feb 2006 22:06:21 -0800 1.546
> +++ Base.pm 17 Feb 2006 11:28:54 -0800
> @@ -449,8 +449,9 @@
>
>
> sub add_build_element {
> - my $self = shift;
> - push @{$self->build_elements}, shift;
> + my ($self, $elem) = @_;
> + $self->install_base_relpaths->{$elem} ||= [$elem];
> + push @{$self->build_elements}, $elem;
>
> }
>
> sub ACTION_config_data {
Any comments on these suggestions? Maybe a different method that does
both of these actions would be welcomed?
sub add_build_element_with_path {
my ($self, $elem) = @_;
$self->add_build_element($elem);
$self->install_base_relpaths->{$elem} ||= [$elem];
}
???
Thanks,
David
|
|
From: Randy W. S. <ml...@th...> - 2006-03-03 20:26:38
|
Ken Williams wrote: > > On Mar 1, 2006, at 5:17 PM, Randy W. Sims wrote: > >> All the solutions I can think of, and the one you mention above are >> all variations on a theme. None of them are ideal, so I have no >> outstanding preference. Options are: >> >> 1) Rearrange the command to put the unquotable(?) construct at the >> end of the command line. Subject to fail later when code is modified >> and inadvertently changes order. >> >> 2) Stuff @ARGV and do 'pl2bat.bat' as you suggest. Makes me nervous; >> kinda depends on knowing pl2bat internals are safe to C<do>. Also, >> more hoops because we have to tie stdin & stdout in place of >> redirection. >> >> 3) Wrap pl2bat in a module and publish it. >> >> 4) Copy the code from pl2bat[1] directly into M::B::P::Windows; It's >> short, and can be abbreviated somewhat for our purpose, but it still >> duplicates code. >> >> I probably like (1) the least, and I guess I lean more towards (3) or >> (4) > > > #3 is certainly The High Road, but it introduces a platform-specific > dependency, and would break from our current rule of no required > dependencies past what's in perl 5.6. Other than that there's probably > no downside. > > #4 is probably the easiest to do in the short term, and actually might > be a decent temporary measure on the way toward #3. How about that, > and then we can plan to publish it separately after 0.28? I got this mostly done last night: <http://thepierianspring.org/perl/Module-Build.tar.gz> I just need to review and test, hopefully getting one more round of tests from Win98 land. Also, I need to update the docs. It mostly duplicates pl2bat with some minor exceptions, but it also cleaned up M::B::P::Windows.pm a good bit: eliminated the constructor override, the _find_pl2bat() method, and greatly simplified the make_executable() method. It works for me. I'll problably check it in sometime this evening, after docs & review; there is no variation in this area on Win98 anymore, so I don't expect failure there related to this issue. Randy. |
|
From: Ken W. <ke...@ma...> - 2006-03-03 19:15:10
|
On Mar 3, 2006, at 8:30 AM, Yitzchak Scott-Thoennes wrote: > > > If the install does in fact fail, does the user end up with an error > later on that is hard to track down to the installation having failed? > (Test by just commenting out the ->install line and see what happens.) In my opinion, no - it's not particularly *pretty*, but it's fairly familiar. The user would first see the installation failing, then they would see an error message saying "Can't find Module::Build::Compat in @INC (...)" like the usual case when a require() goes bad. In general I usually try to avoid catching exceptions and obscuring the original texts of them to try to say something "smarter", but I suppose I could be persuaded to do so in this case if popular sentiment is with it. > BTW, can we get a 0.27_08 release soon? There've been a lot of > changes > since 0.27_07. Definitely. -Ken |
|
From: Yitzchak Scott-T. <sth...@ef...> - 2006-03-03 14:30:13
|
On Wed, Mar 01, 2006 at 09:42:21PM -0600, Ken Williams wrote:
> Hi,
>
> Since it's come up on both these lists recently I thought I should
> mention this and ask for a little feedback. Today I committed a
> patch to Module::Build::Compat:
>
> --- Compat.pm 3 Dec 2005 03:08:14 -0000 1.73
> +++ Compat.pm 1 Mar 2006 22:46:22 -0000 1.74
> @@ -90,8 +90,8 @@
> # Save this 'cause CPAN will chdir all over the place.
> my $cwd = Cwd::cwd();
>
> - CPAN::Shell->install('Module::Build::Compat')
> - or die " *** Cannot install without Module::Build. Exiting ...\n";
> + # There seems to be no way to determine if this install was
> successful
> + CPAN::Shell->install('Module::Build::Compat');
>
> chdir $cwd or die "Cannot chdir() back to $cwd: $!";
> }
>
>
> I did this because I was on Cygwin installing a module that had a
> passthrough Makefile.PL, and I didn't have M::B already installed.
> It offered to use CPAN.pm to install M::B for me, which succeeded,
> and then it died with the above error message, because install()
> returned false even when it was successful.
>
> Inspecting the CPAN.pm code, I can't quite see *why* it returned
> false, but the docs don't say it returns any value in particular, so
> I thought I shouldn't rely on one. I think it might be the case that
> different versions of CPAN return different values, perhaps?
>
> Anyway, this certainly improves its bootstrapping, and probably is
> good enough to go in 0.28? Anyone (dis)?agree, either on facts or
> opinions?
If the install does in fact fail, does the user end up with an error
later on that is hard to track down to the installation having failed?
(Test by just commenting out the ->install line and see what happens.)
If so, after the ->install(), try eval {require
Module::Build::Compat;} and die with an error if it fails?
BTW, can we get a 0.27_08 release soon? There've been a lot of changes
since 0.27_07.
|
|
From: Yitzchak Scott-T. <sth...@ef...> - 2006-03-03 14:13:12
|
On Sat, Feb 25, 2006 at 09:37:13AM -0600, Ken Williams wrote: > > On Feb 24, 2006, at 5:43 PM, Yitzchak Scott-Thoennes wrote: > >Just testing, and apparently really just for VMS, but I think it's > >be better to have all tests go through the same code, so have all > >platforms use it. > > Okay, thanks, applied. Did we ever figure out why the hard-coding > was needed for that last line? No. I think curdir would have been something like "[]". > Is it File::Find being too Unix-centric? Don't know. |
|
From: Ken W. <ke...@ma...> - 2006-03-02 22:24:08
|
On Feb 25, 2006, at 3:51 PM, Randy W. Sims wrote: > Adam Kennedy wrote: >> There's a few classes of checks we can do. >> If the package has a META.yml, it should have a license field. >> There are about a dozen legitimate values. >> license 'restrictive' >> The is an absolute positive match for a disallowed license. >> A check covering the above case could safely be added immediately. >> Beyond that you have three additional cases... >> - The license value exists but is not a known type >> - There is no license value in the META.yml >> - There is no META.yml > > There is a snapshot of how the license field in META.yml is used at: > > <http://thepierianspring.org/perl/meta> [snip] I missed the beginning of this conversation, but since the Beginning Of Time we've rejected any value for the license field that isn't in our list of valid licenses. My guess is that the weird license values in that report were created using MakeMaker or something. -Ken |
|
From: Ken W. <ke...@ma...> - 2006-03-02 03:42:27
|
Hi,
Since it's come up on both these lists recently I thought I should
mention this and ask for a little feedback. Today I committed a
patch to Module::Build::Compat:
--- Compat.pm 3 Dec 2005 03:08:14 -0000 1.73
+++ Compat.pm 1 Mar 2006 22:46:22 -0000 1.74
@@ -90,8 +90,8 @@
# Save this 'cause CPAN will chdir all over the place.
my $cwd = Cwd::cwd();
- CPAN::Shell->install('Module::Build::Compat')
- or die " *** Cannot install without Module::Build. Exiting ...\n";
+ # There seems to be no way to determine if this install was
successful
+ CPAN::Shell->install('Module::Build::Compat');
chdir $cwd or die "Cannot chdir() back to $cwd: $!";
}
I did this because I was on Cygwin installing a module that had a
passthrough Makefile.PL, and I didn't have M::B already installed.
It offered to use CPAN.pm to install M::B for me, which succeeded,
and then it died with the above error message, because install()
returned false even when it was successful.
Inspecting the CPAN.pm code, I can't quite see *why* it returned
false, but the docs don't say it returns any value in particular, so
I thought I shouldn't rely on one. I think it might be the case that
different versions of CPAN return different values, perhaps?
Anyway, this certainly improves its bootstrapping, and probably is
good enough to go in 0.28? Anyone (dis)?agree, either on facts or
opinions?
-Ken
|
|
From: Ken W. <ke...@ma...> - 2006-03-02 02:25:07
|
On Mar 1, 2006, at 5:17 PM, Randy W. Sims wrote: > All the solutions I can think of, and the one you mention above are > all variations on a theme. None of them are ideal, so I have no > outstanding preference. Options are: > > 1) Rearrange the command to put the unquotable(?) construct at the > end of the command line. Subject to fail later when code is > modified and inadvertently changes order. > > 2) Stuff @ARGV and do 'pl2bat.bat' as you suggest. Makes me > nervous; kinda depends on knowing pl2bat internals are safe to > C<do>. Also, more hoops because we have to tie stdin & stdout in > place of redirection. > > 3) Wrap pl2bat in a module and publish it. > > 4) Copy the code from pl2bat[1] directly into M::B::P::Windows; > It's short, and can be abbreviated somewhat for our purpose, but it > still duplicates code. > > I probably like (1) the least, and I guess I lean more towards (3) > or (4) #3 is certainly The High Road, but it introduces a platform-specific dependency, and would break from our current rule of no required dependencies past what's in perl 5.6. Other than that there's probably no downside. #4 is probably the easiest to do in the short term, and actually might be a decent temporary measure on the way toward #3. How about that, and then we can plan to publish it separately after 0.28? -Ken |
|
From: Ken W. <ke...@ma...> - 2006-03-02 02:05:51
|
On Feb 27, 2006, at 10:03 PM, David Golden wrote: > Ken Williams wrote: >> Yup, exactly. I've now fixed that in CVS. > > Psst. Sourceforge now has Subversion.... > > Please! Pretty-please! (Actually, after 0.28 would be fine.) Cool, I hadn't even heard that announcement. I'm not so experienced at svn, but in my other life I'm a perforce power user and sick to death of cvs. Yeah, expect a migration around 0.28-ish. -Ken |
|
From: demerphq <dem...@gm...> - 2006-03-02 00:58:14
|
On 3/2/06, Randy W. Sims <ml...@th...> wrote: > Ken Williams wrote: > > > > On Feb 28, 2006, at 8:33 PM, Randy W. Sims wrote: > > > >> Ken Williams wrote: > >>> On Feb 25, 2006, at 1:32 PM, Randy W. Sims wrote: > >>>> Ok, here's the problem. The quoting is wrong in the invokation of > >>>> pl2bat. Both arguments to pl2bat got bungled into one misformed arg. > >>>> I need to figure out how to invoke pl2bat from the command line with > >>>> corrected quoting. The command we're using now, that produces the > >>>> bungled last line above is: > >>>> > >>>> pl2bat -n "-x -S """%0""" --build_bat %*" -o "-x -S """%0""" > >>>> --build_bat %1 %2 %3 %4 %5 %6 %7 %8 %9" < Build > Build.bat > >>>> > >>>> It looks like it is trying to expand %*" -o "-x -S """% as an > >>>> evironment var. Maybe an extra space after %*: > >>>> > >>>> pl2bat -n "-x -S """%0""" --build_bat %* " -o "-x -S """%0""" > >>>> --build_bat %1 %2 %3 %4 %5 %6 %7 %8 %9 " < Build > Build.bat > >>>> > >>>> Otherwise, I'm not sure how to quote the percent symbol (%%* doesn't > >>>> work). I've posted a message over on alt.msdos.batch about this. > >>> Won't the multi-argument form of system() be helpful here? It's > >>> generally much easier to get that to work out than trying to get > >>> quoting right. > >> > >> It doesn't seem so... In order to use redirection in the command > >> that's executed, the shell must be invoked. > > > > Yuck. Short of converting pl2bat into module form, is there some other > > sneaky solution? Maybe set @ARGV and then do($pl2bat), with STDOUT tie= d? > > > > If there's one thing I hate, it's shell quoting just to call another se= t > > of perl code. > > All the solutions I can think of, and the one you mention above are all > variations on a theme. None of them are ideal, so I have no outstanding > preference. Options are: > > 1) Rearrange the command to put the unquotable(?) construct at the end > of the command line. Subject to fail later when code is modified and > inadvertently changes order. > > 2) Stuff @ARGV and do 'pl2bat.bat' as you suggest. Makes me nervous; > kinda depends on knowing pl2bat internals are safe to C<do>. Also, more > hoops because we have to tie stdin & stdout in place of redirection. > > 3) Wrap pl2bat in a module and publish it. > > 4) Copy the code from pl2bat[1] directly into M::B::P::Windows; It's > short, and can be abbreviated somewhat for our purpose, but it still > duplicates code. > > I probably like (1) the least, and I guess I lean more towards (3) or (4) > > Your preference? FWIW: #3 Yves -- perl -Mre=3Ddebug -e "/just|another|perl|hacker/" |
|
From: Randy W. S. <ml...@th...> - 2006-03-01 23:17:27
|
Ken Williams wrote: > > On Feb 28, 2006, at 8:33 PM, Randy W. Sims wrote: > >> Ken Williams wrote: >>> On Feb 25, 2006, at 1:32 PM, Randy W. Sims wrote: >>>> Ok, here's the problem. The quoting is wrong in the invokation of >>>> pl2bat. Both arguments to pl2bat got bungled into one misformed arg. >>>> I need to figure out how to invoke pl2bat from the command line with >>>> corrected quoting. The command we're using now, that produces the >>>> bungled last line above is: >>>> >>>> pl2bat -n "-x -S """%0""" --build_bat %*" -o "-x -S """%0""" >>>> --build_bat %1 %2 %3 %4 %5 %6 %7 %8 %9" < Build > Build.bat >>>> >>>> It looks like it is trying to expand %*" -o "-x -S """% as an >>>> evironment var. Maybe an extra space after %*: >>>> >>>> pl2bat -n "-x -S """%0""" --build_bat %* " -o "-x -S """%0""" >>>> --build_bat %1 %2 %3 %4 %5 %6 %7 %8 %9 " < Build > Build.bat >>>> >>>> Otherwise, I'm not sure how to quote the percent symbol (%%* doesn't >>>> work). I've posted a message over on alt.msdos.batch about this. >>> Won't the multi-argument form of system() be helpful here? It's >>> generally much easier to get that to work out than trying to get >>> quoting right. >> >> It doesn't seem so... In order to use redirection in the command >> that's executed, the shell must be invoked. > > Yuck. Short of converting pl2bat into module form, is there some other > sneaky solution? Maybe set @ARGV and then do($pl2bat), with STDOUT tied? > > If there's one thing I hate, it's shell quoting just to call another set > of perl code. All the solutions I can think of, and the one you mention above are all variations on a theme. None of them are ideal, so I have no outstanding preference. Options are: 1) Rearrange the command to put the unquotable(?) construct at the end of the command line. Subject to fail later when code is modified and inadvertently changes order. 2) Stuff @ARGV and do 'pl2bat.bat' as you suggest. Makes me nervous; kinda depends on knowing pl2bat internals are safe to C<do>. Also, more hoops because we have to tie stdin & stdout in place of redirection. 3) Wrap pl2bat in a module and publish it. 4) Copy the code from pl2bat[1] directly into M::B::P::Windows; It's short, and can be abbreviated somewhat for our purpose, but it still duplicates code. I probably like (1) the least, and I guess I lean more towards (3) or (4) Your preference? Randy. 1. <http://search.cpan.org/src/NWCLARK/perl-5.8.8/win32/bin/pl2bat.pl> |
|
From: Ron S. <ro...@sa...> - 2006-03-01 22:51:16
|
On Wed, 01 Mar 2006 15:36:24 +1100, Ron Savage wrote: Hi Ron > A week or two ago I stumbled across a web page at Microsoft which > covered this topic. Know what it might have been? Not what I was thinking of, but may help: o http://mailman.lyra.org/pipermail/scite-interest/2002-March/000436.html o http://tinyurl.com/oum4x (i.e.: http://msdn.microsoft.com/library/default.asp?url=3D/library/en-us/vclang/html= /_pl uslang_Parsing_C.2b2b_.Command.2d.Line_Arguments.asp) -- Cheers Ron Savage, ro...@sa... on 1/03/2006 http://savage.net.au/index.html Let the record show: Microsoft is not an Australian company |
|
From: demerphq <dem...@gm...> - 2006-03-01 07:59:38
|
On 3/1/06, Dr Bean <gr...@mo...> wrote: > There were a lot of error messages about Tie::CPHash not being found. > > I put that in the lib directory and it is hanging again at subtest 25 of > basic.t > > But Build realclean works. Am I correct that this is Win98? -- perl -Mre=3Ddebug -e "/just|another|perl|hacker/" |
|
From: Dr B. <gr...@mo...> - 2006-03-01 04:52:50
|
On Tue, 28 Feb 2006, Randy W. Sims wrote: > <http://thepierianspring.org/perl/Module-Build.tar.gz> D:\greg\Module-Build>Build realclean Deleting _build Deleting Build D:\greg\Module-Build>dir build Volume in drive D has no label Volume Serial Number is 4658-17D7 Directory of D:\greg\Module-Build BUILD PL 2,591 02-02-06 8:19 Build.PL 1 file(s) 2,591 bytes 0 dir(s) 13,721.52 MB free D:\greg\Module-Build> D:\greg\Module-Build>perl Build realclean Deleting _build Deleting Build Deleting Build.bat D:\greg\Module-Build>dir build Volume in drive D has no label Volume Serial Number is 4658-17D7 Directory of D:\greg\Module-Build BUILD PL 2,591 02-02-06 8:19 Build.PL 1 file(s) 2,591 bytes 0 dir(s) 13,721.52 MB free D:\greg\Module-Build> > If everything works could you post the batch heading of Build.bat? @rem = '--*-Perl-*-- @echo off if "%OS%" == "Windows_NT" goto WinNT perl -x -S "%0" --build_bat %1 %2 %3 %4 %5 %6 %7 %8 %9 goto endofperl :WinNT perl -x -S "%0" --build_bat %* if NOT "%COMSPEC%" == "%SystemRoot%\system32\cmd.exe" goto endofperl if %errorlevel% == 9009 echo You do not have Perl in your PATH. if errorlevel 1 goto script_failed_so_exit_with_non_zero_val 2>nul goto endofperl @rem '; #!perl #line 15 use strict; use Cwd; use File::Basename; > Build test Failed Test Stat Wstat Total Fail Failed List of Failed ----------------------------------------------------------------------------- t\basic.t 2 512 55 110 200.00% 1-55 t\compat.t 2 512 ?? ?? % ?? t\destinations.t 2 512 92 184 200.00% 1-92 t\extend.t 2 512 53 106 200.00% 1-53 t\files.t 2 512 6 12 200.00% 1-6 t\install.t 2 512 34 68 200.00% 1-34 t\manifypods.t 2 512 ?? ?? % ?? t\metadata.t 2 512 46 92 200.00% 1-46 t\metadata2.t 2 512 18 36 200.00% 1-18 t\moduleinfo.t 2 512 66 132 200.00% 1-66 t\notes.t 2 512 11 22 200.00% 1-11 t\ppm.t 2 512 ?? ?? % ?? t\runthrough.t 2 512 28 56 200.00% 1-28 t\signature.t 2 512 ?? ?? % ?? t\tilde.t 2 512 11 22 200.00% 1-11 t\versions.t 2 512 2 4 200.00% 1-2 t\xs.t 2 512 ?? ?? % ?? Failed 17/20 test scripts, 15.00% okay. 422/548 subtests failed, 22.99% okay. D:\greg\Module-Build> There were a lot of error messages about Tie::CPHash not being found. I put that in the lib directory and it is hanging again at subtest 25 of basic.t But Build realclean works. -- Dr Bean Whereof we cannot speak, we must remain silent. --Ludwig Wittgenstein We know more than we can say. --Michael Polanyi |
|
From: Ken W. <ke...@ma...> - 2006-03-01 04:49:47
|
On Feb 28, 2006, at 8:33 PM, Randy W. Sims wrote: > Ken Williams wrote: >> On Feb 25, 2006, at 1:32 PM, Randy W. Sims wrote: >>> Ok, here's the problem. The quoting is wrong in the invokation of >>> pl2bat. Both arguments to pl2bat got bungled into one misformed >>> arg. I need to figure out how to invoke pl2bat from the command >>> line with corrected quoting. The command we're using now, that >>> produces the bungled last line above is: >>> >>> pl2bat -n "-x -S """%0""" --build_bat %*" -o "-x -S """%0""" -- >>> build_bat %1 %2 %3 %4 %5 %6 %7 %8 %9" < Build > Build.bat >>> >>> It looks like it is trying to expand %*" -o "-x -S """% as an >>> evironment var. Maybe an extra space after %*: >>> >>> pl2bat -n "-x -S """%0""" --build_bat %* " -o "-x -S """%0""" -- >>> build_bat %1 %2 %3 %4 %5 %6 %7 %8 %9 " < Build > Build.bat >>> >>> Otherwise, I'm not sure how to quote the percent symbol (%%* >>> doesn't work). I've posted a message over on alt.msdos.batch >>> about this. >> Won't the multi-argument form of system() be helpful here? It's >> generally much easier to get that to work out than trying to get >> quoting right. > > It doesn't seem so... In order to use redirection in the command > that's executed, the shell must be invoked. Yuck. Short of converting pl2bat into module form, is there some other sneaky solution? Maybe set @ARGV and then do($pl2bat), with STDOUT tied? If there's one thing I hate, it's shell quoting just to call another set of perl code. -Ken |
|
From: Ron S. <ro...@sa...> - 2006-03-01 04:44:01
|
On Tue, 28 Feb 2006 21:33:02 -0500, Randy W. Sims wrote: Hi Randy WinXP here. > perl Build.PL > Build realclean > if not exist Build.bat echo hallelujah Echos the text > perl Build.PL > perl Build realclean > if not exist Build.bat echo hallelujah Echos the text > perl Build.PL > > If everything works could you post the batch heading of Build.bat? Meaning? > Build > Build test Missing Tie/CPHash (because missing t/bundled/*) > Build realclean No errors from the shell, and no Build.bat at this point. -- Ron Savage ro...@sa... http://savage.net.au/index.html |
|
From: Ron S. <ro...@sa...> - 2006-03-01 04:40:51
|
On Tue, 28 Feb 2006 22:31:48 -0500, David Golden wrote: Hi David A week or two ago I stumbled across a web page at Microsoft which covered this topic. Know what it might have been? -- Ron Savage ro...@sa... http://savage.net.au/index.html |
|
From: David G. <da...@hy...> - 2006-03-01 03:31:59
|
Randy W. Sims wrote:
>>> Otherwise, I'm not sure how to quote the percent symbol (%%* doesn't
>>> work). I've posted a message over on alt.msdos.batch about this.
>>
>> Won't the multi-argument form of system() be helpful here? It's
>> generally much easier to get that to work out than trying to get
>> quoting right.
>
> It doesn't seem so... In order to use redirection in the command that's
> executed, the shell must be invoked. If you use the multiple arg form of
> system, you have to explicitly specify the shell. The problem is the
> shell then requires the syntax:
>
> $shell /C "$string"
I've been deleting this thread for a while for lack of time to read it,
but caught up briefly here. I apologize if this has been discussed
already or you're well beyond it, but Roderich Schupp and I had a short
exchange a while ago about windows shell quoting in discussing
improvement to IPC::Run3. In short, we concluded it's really ugly. By
triangulating between Perl, Haskell and gtk/glib source and comments, he
came up with the following escaping algorithm:
sub protect_argv_string
{
my ($p) = @_;
(my $q = $p) =~ s/(\\*)"/$1$1\\"/g;
$q = qq["$q"] if $p =~ /[ \t]/;
return $q;
}
That said, I don't think we ever came up with a way of properly escaping
"%". You can precede it with a backslash it to prevent it from being
interpreted as an environment variable, but the backslash itself appears
in the output.
Regards,
David
|
|
From: Randy W. S. <ml...@th...> - 2006-03-01 02:33:07
|
Ken Williams wrote: > > On Feb 25, 2006, at 1:32 PM, Randy W. Sims wrote: > >> Ok, here's the problem. The quoting is wrong in the invokation of >> pl2bat. Both arguments to pl2bat got bungled into one misformed arg. I >> need to figure out how to invoke pl2bat from the command line with >> corrected quoting. The command we're using now, that produces the >> bungled last line above is: >> >> pl2bat -n "-x -S """%0""" --build_bat %*" -o "-x -S """%0""" >> --build_bat %1 %2 %3 %4 %5 %6 %7 %8 %9" < Build > Build.bat >> >> It looks like it is trying to expand %*" -o "-x -S """% as an >> evironment var. Maybe an extra space after %*: >> >> pl2bat -n "-x -S """%0""" --build_bat %* " -o "-x -S """%0""" >> --build_bat %1 %2 %3 %4 %5 %6 %7 %8 %9 " < Build > Build.bat >> >> Otherwise, I'm not sure how to quote the percent symbol (%%* doesn't >> work). I've posted a message over on alt.msdos.batch about this. > > Won't the multi-argument form of system() be helpful here? It's > generally much easier to get that to work out than trying to get quoting > right. It doesn't seem so... In order to use redirection in the command that's executed, the shell must be invoked. If you use the multiple arg form of system, you have to explicitly specify the shell. The problem is the shell then requires the syntax: $shell /C "$string" I.E. it only accepts a single string to execute. Using the undocumented(?) trick of passing a 1 as the first arg to system() doesn't help here either. I still haven't received a solution on alt.msdos.batch. Maybe we can fudge a solution. If we rearrange the line so that the problem part is at the end of the string, it won't matter if quoting is wrong: it will be terminated by the end of line. This is a big kludge IMO, but until something else presents here is a snapshot to try out. <http://thepierianspring.org/perl/Module-Build.tar.gz> perl Build.PL Build realclean if not exist Build.bat echo hallelujah perl Build.PL perl Build realclean if not exist Build.bat echo hallelujah perl Build.PL If everything works could you post the batch heading of Build.bat? Build Build test Build realclean Thanks, Randy. |
|
From: Ken W. <ke...@ma...> - 2006-02-28 23:04:33
|
On Feb 28, 2006, at 11:39 AM, demerphq wrote: > On 2/28/06, David E. Wheeler <da...@ki...> wrote: >> On Feb 28, 2006, at 09:16, demerphq wrote: >> >>> Yeah, i know. Its the bit "out of the box" that I feel is important. >>> Why should perl ever install a file a with .svn into the tree? >> >> The default MANIFEST.skip has come with "\.svn" for some time. > > Oh cool. :-) > > Er, As produced by MB? Or by something else? The skinny: * If no MANIFEST.skip file is present when running the 'manifest' action, M::B will create one that does indeed know about .svn dirs. * h2xs doesn't produce a MANIFEST.SKIP at all, AFAIK * ExtUtils::Manifest never creates a MANIFEST.SKIP file either AFAIK, but it does have a default set of stuff it will skip when no MANIFEST.SKIP is present. -Ken |
7 messages has been excluded from this view by a project administrator.
