module-build-general Mailing List for Module::Build (Page 23)
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: David E. W. <da...@ki...> - 2006-02-28 17:56:36
|
On Feb 28, 2006, at 09:49, demerphq wrote: > Ah, cool. Ill have to upgrade and then delete my old one and see > what happens. Actually, thinking on it, it's probably h2xs (and Module::Starter and its ilk) that create this file. But maybe M::B does, too. I'm not sure. Best, David |
|
From: demerphq <dem...@gm...> - 2006-02-28 17:49:20
|
On 2/28/06, David E. Wheeler <da...@ki...> wrote: > On Feb 28, 2006, at 09:39, demerphq wrote: > > > Oh cool. :-) > > > > Er, As produced by MB? Or by something else? > > I believe it is ExtUtils::Manifest. So both. Ah, cool. Ill have to upgrade and then delete my old one and see what happe= ns. Thanks a lot. Yves -- perl -Mre=3Ddebug -e "/just|another|perl|hacker/" |
|
From: David E. W. <da...@ki...> - 2006-02-28 17:44:50
|
On Feb 28, 2006, at 09:39, demerphq wrote: > Oh cool. :-) > > Er, As produced by MB? Or by something else? I believe it is ExtUtils::Manifest. So both. Best, David |
|
From: demerphq <dem...@gm...> - 2006-02-28 17:40:02
|
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? cheers, Yves -- perl -Mre=3Ddebug -e "/just|another|perl|hacker/" |
|
From: David E. W. <da...@ki...> - 2006-02-28 17:35:59
|
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. Best, David |
|
From: demerphq <dem...@gm...> - 2006-02-28 17:17:01
|
On 2/28/06, David Golden <da...@hy...> wrote: > demerphq wrote: > > It would be cool if MB and EUMM were svn aware out of the box*. I put > > Data::Dump::Streamer into SVN and was surprised to discover that when > > I do an install it also installs the svn checkout folders too. Wahey, > > there is an advantage to using SourceSafe after all ;-) > > > > Yves > > * This would apply to any other SC systems that is widely used and has > > similar issues. > > That's a MANIFEST.SKIP issue. Just add "^.svn/" to your MANIFEST.SKIP > and you're all set. 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? > Alternatively, use SVK, which doesn't add hidden directories to your > checked-out directories. It uses Subversion behind the scenes and saves > you that hassle. On the other hand, check-out dirs can't be freely > relocated as you can with Subversion check-outs. That I didnt know. Thanks. Ill look into that. Yves -- perl -Mre=3Ddebug -e "/just|another|perl|hacker/" |
|
From: David G. <da...@hy...> - 2006-02-28 15:34:58
|
demerphq wrote: > It would be cool if MB and EUMM were svn aware out of the box*. I put > Data::Dump::Streamer into SVN and was surprised to discover that when > I do an install it also installs the svn checkout folders too. Wahey, > there is an advantage to using SourceSafe after all ;-) > > Yves > * This would apply to any other SC systems that is widely used and has > similar issues. That's a MANIFEST.SKIP issue. Just add "^.svn/" to your MANIFEST.SKIP and you're all set. Alternatively, use SVK, which doesn't add hidden directories to your checked-out directories. It uses Subversion behind the scenes and saves you that hassle. On the other hand, check-out dirs can't be freely relocated as you can with Subversion check-outs. Regards, David |
|
From: demerphq <dem...@gm...> - 2006-02-28 08:59:03
|
On 2/28/06, David Golden <da...@hy...> 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.) > > But I'd *really* like to be able to use Subversion/SVK to hack > Module::Build. At least for me, it would definitely lower the > contribution hurdle. It might for others as well, particularly if you > can allow users their own private branches they can commit to; that > others can pull from; and that you can pull from to merge changes. It would be cool if MB and EUMM were svn aware out of the box*. I put Data::Dump::Streamer into SVN and was surprised to discover that when I do an install it also installs the svn checkout folders too. Wahey, there is an advantage to using SourceSafe after all ;-) Yves * This would apply to any other SC systems that is widely used and has similar issues. -- perl -Mre=3Ddebug -e "/just|another|perl|hacker/" |
|
From: David G. <da...@hy...> - 2006-02-28 04:03:44
|
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.) But I'd *really* like to be able to use Subversion/SVK to hack Module::Build. At least for me, it would definitely lower the contribution hurdle. It might for others as well, particularly if you can allow users their own private branches they can commit to; that others can pull from; and that you can pull from to merge changes. Regards, David Golden |
|
From: Ken W. <ke...@ma...> - 2006-02-27 13:20:12
|
On Feb 27, 2006, at 3:29 AM, Yitzchak Scott-Thoennes wrote: > On Sun, Feb 26, 2006 at 10:26:20PM -0500, John Peacock wrote: >> Ken Williams wrote: >>> I noticed the subclass just wraps this method in an eval() and >>> returns >>> false when the eval() fails. Has that been a problem? >> >> I believe that is the only way to prevent the build from dying if >> there is no C compiler (i.e. I think this is what M::B should be >> doing internally). > > Maybe I'm misremembering, but I thought the problem was that it was > dying when there was no ExtUtils::CBuilder installed, but if EU::CB > was there it would run without dying even with no C compiler. Yup, exactly. I've now fixed that in CVS. -Ken |
|
From: Yitzchak Scott-T. <sth...@ef...> - 2006-02-27 09:50:37
|
This was a problem with a win32 build using the cygwin compiler in its
mingw cross-compilation mode.
On Sun, Feb 26, 2006 at 08:02:48PM -0600, Ken Williams wrote:
> Hi guys,
>
> How come a cygwin issue needs a patch in Windows.pm? Or is this just
> a general Windows issue with us doing the shell quoting wrong?
>
> -Ken
>
>
> On Feb 21, 2006, at 3:27 AM, Randy W. Sims wrote:
>
> >Yitzchak Scott-Thoennes wrote:
> >>Cygwin programs when run by non-cygwin programs do not interpret
> >>\" as
> >>an escaped " except within "". This results in errors like the
> >>following when using cygwin gcc in "mingw" mode:
> >>gcc -mno-cygwin -c -s -O2 -DWIN32 -DHAVE_DES_FCRYPT -
> >>DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -fno-strict-aliasing -
> >>DPERL_MSVCRT_READFIX -s -O2 -DXS_VERSION=\"0.01\" -DVERSION=\"0.01
> >>\" -I"..\..\..\lib\CORE" -I"C:\MinGW\include" -o "lib\Simple.o"
> >>"lib\Simple.c"
> >>gcc: no input files
> >>error building dll file from 'lib\Simple.c' at C:\cygwin\home
> >>\sthoenna\bleadperl\wp\lib/ExtUtils/CBuilder/Platform/Windows.pm
> >>line 143.
> >>The first backslash in -DXS_VERSION=\"0.01\" is treated as a literal
> >>backslash, and the " after it starts a quoted string, resulting in
> >>gcc
> >>getting everything after -O2 as a single argument:
> >> -DXS_VERSION=\0.01" -DVERSION="0.01" -I......libCORE -
> >>IC:MinGWinclude -o libSimple.o libSimple.c
> >>The following patch fixes this and in theory should not cause any
> >>problems.
> >
> >Thanks. I've checked this into CVS.
> >
> >Randy.
> >
> >
> >>--- lib/ExtUtils/CBuilder/Platform/Windows.pm.orig 2005-10-04
> >>04:32:20.000000000 -0700
> >>+++ lib/ExtUtils/CBuilder/Platform/Windows.pm 2006-01-09
> >>19:55:07.807132800 -0800
> >>@@ -93,7 +93,7 @@
> >> sub arg_defines {
> >> my ($self, %args) = @_;
> >> s/"/\\"/g foreach values %args;
> >>- return map "-D$_=$args{$_}", keys %args;
> >>+ return map qq{"-D$_=$args{$_}"}, keys %args;
> >> }
>
|
|
From: Yitzchak Scott-T. <sth...@ef...> - 2006-02-27 09:29:13
|
On Sun, Feb 26, 2006 at 10:26:20PM -0500, John Peacock wrote: > Ken Williams wrote: > > I noticed the subclass just wraps this method in an eval() and returns > > false when the eval() fails. Has that been a problem? > > I believe that is the only way to prevent the build from dying if > there is no C compiler (i.e. I think this is what M::B should be > doing internally). Maybe I'm misremembering, but I thought the problem was that it was dying when there was no ExtUtils::CBuilder installed, but if EU::CB was there it would run without dying even with no C compiler. |
|
From: Ken W. <ke...@ma...> - 2006-02-27 03:47:08
|
Hi John,
Thanks for the patch - I actually just committed a different patch
with essentially the same effect, but instead of using eval{} it just
doesn't throw the exception in the first place. That exception
should be thrown in compile_c() and link_c(), not in _cbuilder().
-Ken
On Feb 19, 2006, at 10:53 AM, John Peacock wrote:
> This should have the correct behavior on machines without any C
> compiler at all:
>
> === lib/Module/Build/Base.pm
> ==================================================================
> --- lib/Module/Build/Base.pm (revision 1834)
> +++ lib/Module/Build/Base.pm (local)
> @@ -3497,7 +3497,8 @@
> return $p->{have_compiler} if defined $p->{have_compiler};
>
> $self->log_verbose("Checking if compiler tools configured... ");
> - my $have = $self->_cbuilder->have_compiler;
> + my $have = eval { $self->_cbuilder->have_compiler };
> + $have = 0 if $@; # no compiler support possible
> $self->log_verbose($have ? "ok.\n" : "failed.\n");
> return $p->{have_compiler} = $have;
> }
>
> It's kind of not fair to provide a function testing whether there
> is an
> effective C compiler available and then die if there isn't (and no
> fallback
> either). :(
|
|
From: Ken W. <ke...@ma...> - 2006-02-27 03:42:22
|
On Feb 19, 2006, at 3:51 PM, Stephen Adkins wrote: > It has already been stated that the subset of the YAML > specification actually > needed by Module::Build is quite limited. > > Why not write a module (Module::Build::YAML) which is included in > the M::B > distribution which supplies all of the YAML functionality required > by M::B. > Then there would never again be a system which had M::B but did not > have > enough YAML support in order to support its functions? Yes, I've been coming to the same conclusion. I think it's probably the right way to go in this situation - we only write YAML, never read it, and the subset of things we need to know how to write is pretty simple. Witness the existing _yaml_quote_string() method, which is darn close to doing everything we need for YAML-writing (though I'm not quite sure it's totally correct). > If people thought this was a good idea (and the solution to some of > these > problems), I would be happy to write it. (But it's not so hard, and > I imagine > others could write it too and not have to wait for me.) That would be awesome. I think the set of types we need to write in YAML are: * Strings * Booleans * Arrays whose entries are members of this set * Hashes whose entries are members of this set and no reference loops. So to do arrays, for example, you can just recurse on the elements of the array. -Ken |
|
From: John P. <jpe...@ro...> - 2006-02-27 03:26:11
|
Ken Williams wrote: > I noticed the subclass just wraps this method in an eval() and returns > false when the eval() fails. Has that been a problem? I believe that is the only way to prevent the build from dying if there is no C compiler (i.e. I think this is what M::B should be doing internally). > On my OS X machine with perl 5.8.6 and M::B 0.27_03 I get some funny > output from running 'perl Build.PL': > > --------------------------- > Creating custom builder _build/lib/version/Builder.pm in _build/lib/ > version > Checking whether your kit is complete... > Looks good > > Checking prerequisites... > Looks good > > Checking whether your kit is complete... > Looks good > > Checking prerequisites... > Looks good > > Creating new 'Build' script for 'version' version '0.56_03' > --------------------------- > > Looks like that's because you're calling new() twice. That's to work > around some problem though, right? Yeah, I'm not sure the best way around that. I need to call new() once to get the commandline argument and then build up the real build arguments based on whether the commandline "--perl_only" was passed in or if there is no C compiler available. I asked at one point about being able to take an existing M::B object and update all of the configuration based on information gathered during the initial object creation. I believe the reponse was something along the line of "that would be nice but for the moment new() is run-once" (I'm paraphrasing). > I also get tons of verbose output from 'Build test', do you see that too? Yeah, I finally figured out to look at Test::Harness for how to determine whether the tests are being run with verbose enabled (duh). Those test section headings will vanish in the next release. John -- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4720 Boston Way Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5747 |
|
From: Ken W. <ke...@ma...> - 2006-02-27 02:24:04
|
On Feb 19, 2006, at 10:40 AM, John Peacock wrote: > Yitzchak Scott-Thoennes wrote: >> $ perl Build.PL >> Checking whether your kit is complete... >> Looks good >> >> Checking prerequisites... >> Looks good >> >> Module::Build is not configured with C_support at /usr/lib/perl5/ >> site_perl/5.8/Module/Build/Base.pm line 3478. > > Bugger. How can I check for a C compiler if the test dies while > trying to > determine if there is a C compiler because it won't create a > c_builder object if > there isn't a C compiler? Arghhh! Grr, yeah. We shouldn't be dying there. I'll fix. -Ken |
|
From: Ken W. <ke...@ma...> - 2006-02-27 02:20:20
|
On Feb 20, 2006, at 10:10 AM, John Peacock wrote: > I've released a beta of version.pm to CPAN that includes the > following: > > 1) code to correctly detect the lack of a working C compiler and > install the > pure Perl module instead (overloading the have_c_compiler sub); I noticed the subclass just wraps this method in an eval() and returns false when the eval() fails. Has that been a problem? > I've tested this on Linux and Cygwin using M::B 0.2611 and 0.27_03 > (my Win32 > machine seems to have forgotten it ever had Perl installed). I'd > really > appreciate any other testing that people can get for me > (specifically where you > don't have a compiler). On my OS X machine with perl 5.8.6 and M::B 0.27_03 I get some funny output from running 'perl Build.PL': --------------------------- Creating custom builder _build/lib/version/Builder.pm in _build/lib/ version Checking whether your kit is complete... Looks good Checking prerequisites... Looks good Checking whether your kit is complete... Looks good Checking prerequisites... Looks good Creating new 'Build' script for 'version' version '0.56_03' --------------------------- Looks like that's because you're calling new() twice. That's to work around some problem though, right? I also get tons of verbose output from 'Build test', do you see that too? --------------------------- t/01base.......ok 1/0# Tests with base class # tests with bare numbers # tests with quoted numbers # tests with stringify # test illegal formats t/01base.......ok 10/0# tests with self # tests with non-objects t/01base.......ok 28/0# tests with objects # numeric tests with non-objects ... --------------------------- -Ken |
|
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 |
|
From: Ken W. <ke...@ma...> - 2006-02-27 02:02:57
|
Hi guys,
How come a cygwin issue needs a patch in Windows.pm? Or is this just
a general Windows issue with us doing the shell quoting wrong?
-Ken
On Feb 21, 2006, at 3:27 AM, Randy W. Sims wrote:
> Yitzchak Scott-Thoennes wrote:
>> Cygwin programs when run by non-cygwin programs do not interpret
>> \" as
>> an escaped " except within "". This results in errors like the
>> following when using cygwin gcc in "mingw" mode:
>> gcc -mno-cygwin -c -s -O2 -DWIN32 -DHAVE_DES_FCRYPT -
>> DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -fno-strict-aliasing -
>> DPERL_MSVCRT_READFIX -s -O2 -DXS_VERSION=\"0.01\" -DVERSION=\"0.01
>> \" -I"..\..\..\lib\CORE" -I"C:\MinGW\include" -o "lib\Simple.o"
>> "lib\Simple.c"
>> gcc: no input files
>> error building dll file from 'lib\Simple.c' at C:\cygwin\home
>> \sthoenna\bleadperl\wp\lib/ExtUtils/CBuilder/Platform/Windows.pm
>> line 143.
>> The first backslash in -DXS_VERSION=\"0.01\" is treated as a literal
>> backslash, and the " after it starts a quoted string, resulting in
>> gcc
>> getting everything after -O2 as a single argument:
>> -DXS_VERSION=\0.01" -DVERSION="0.01" -I......libCORE -
>> IC:MinGWinclude -o libSimple.o libSimple.c
>> The following patch fixes this and in theory should not cause any
>> problems.
>
> Thanks. I've checked this into CVS.
>
> Randy.
>
>
>> --- lib/ExtUtils/CBuilder/Platform/Windows.pm.orig 2005-10-04
>> 04:32:20.000000000 -0700
>> +++ lib/ExtUtils/CBuilder/Platform/Windows.pm 2006-01-09
>> 19:55:07.807132800 -0800
>> @@ -93,7 +93,7 @@
>> sub arg_defines {
>> my ($self, %args) = @_;
>> s/"/\\"/g foreach values %args;
>> - return map "-D$_=$args{$_}", keys %args;
>> + return map qq{"-D$_=$args{$_}"}, keys %args;
>> }
|
|
From: demerphq <dem...@gm...> - 2006-02-26 12:39:03
|
On 2/26/06, Dr Bean <gr...@mo...> wrote: > On Sat, 25 Feb 2006, Randy W. Sims wrote: > > > pl2bat -n "-x -S """%0""" --build_bat %*" -o "-x -S """%0""" --build_ba= t > > %1 %2 %3 %4 %5 %6 %7 %8 %9" < Build > Build.bat > > > 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 > > Both of those commands, run from the command line are hanging > here. > > But 'pl2bat --help' is hanging also, though 'pl2bat -h' doesn't. I vaguely recall that %* isnt supported on Win 9x. But i havent verified th= is. Yves -- perl -Mre=3Ddebug -e "/just|another|perl|hacker/" |
|
From: Dr B. <gr...@mo...> - 2006-02-26 09:56:36
|
On Sat, 25 Feb 2006, Randy W. Sims wrote: > 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 > 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 Both of those commands, run from the command line are hanging here. But 'pl2bat --help' is hanging also, though 'pl2bat -h' doesn't. -- drbean |
|
From: <and...@fr...> - 2006-02-26 08:38:52
|
>>>>> On Sat, 25 Feb 2006 16:51:10 -0500, "Randy W. Sims" <Ra...@Th...> said: > There is a snapshot of how the license field in META.yml is used at: Very nice work, thank you! I have also collected a few data from the DSLIP status. This is based on what the authors fill into a form on PAUSE when they register a namespace. It is based on modules/namespaces, not as META.yml-data, on distributions. not registered 33389 Artistic 117 BSD 41 GPL 233 LGPL 46 Standard-Perl 1818 distribution_allowed 18 no_licence 13 open-source 81 restricted_distribution 8 unknown 1433 I'm currently unable to draw any conclusions but sure thing is, we have many white spots on the map but also a strong fundament of standard perl licensed stuff. -- andreas |
|
From: Ron S. <ro...@sa...> - 2006-02-26 01:31:14
|
On Fri, 24 Feb 2006 21:27:30 -0500, Randy W. Sims wrote: Hi Randy > perl Build.PL > Build realclean > if exist Build.bat echo profanity WIn2K. I did a 'perl Build test' and then a 'perl Build realclean'. The= latter produced: C:\perl-modules\Module-Build>perl Build realclean Deleting pod2htmd.tmp Deleting pod2htmi.tmp Deleting blib Deleting _build Deleting Build ######################################## build_bat: 0 $VAR1 =3D 'ARGV'; $VAR2 =3D []; ######################################## Deleting Build.bat -- Cheers Ron Savage, ro...@sa... on 26/02/2006 http://savage.net.au/index.html Let the record show: Microsoft is not an Australian company |
|
From: John P. <jpe...@ro...> - 2006-02-26 00:00:34
|
Randy W. Sims wrote:
> while (my ($file, $to) = each %$files) {
> unless ($self->up_to_date( $file, $to )) {
> $self->run_perl_script($file, [], [@$to]);
> $self->add_to_cleanup(@$to);
That does seem like it should DTRT.
> Under what conditions does it fail to clean up?
I noticed it failing in my development directory, in this instance for
SVN::Notify::Mirror. If I expand the tar into a temp directory (like CPANPLUS
would do), everything works fine. I just tried to reproduce the problem by
manually deleting the files in question and then going through:
$ perl Build.PL
$ ./Build test
$ ./Build distclean
and this time the generated files were deleted (though I swear I already went
through this loop several times).
Mark it down as a Heisenbug...
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747
|
|
From: Tyler M. <ty...@yi...> - 2006-02-25 23:19:09
|
I have a function that does this to get database settings, to test an
apache2 handler that uses a database:
sub test_db {
my $build = Apache::TestMB->current;
return unless $build->notes('DBI_DSN');
return map {
defined $build->notes($_) ? $build->notes($_) : ''
} qw(DBI_DSN DBI_USER DBI_PASS);
}
When I grab these values from within extra.last.conf.in, the function
returns successfully and gives me the right settings right away. However,
Apache::Test's apache2 times out waiting for the server to start. I get the
same result with Module::Build->current.
When I set these in my extra.conf.last.in manually, everything works and my
tests pass.
I'm kind of confused as to how invoking a Module::Build object could cause
the server to hang long after the object has been destroyed. Any ideas?
For now, I'm just doing to do() the _build/notes file to get this config
data.
Cheers,
Tyler
|
7 messages has been excluded from this view by a project administrator.
