module-build-general Mailing List for Module::Build (Page 171)
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...> - 2003-05-07 22:32:42
|
Hey, I'm about to commit a patch that makes copy_if_modified() take named parameters. I've done so in a way that lets old-style $self->copy_if_modified($from, $to_dir, $flatten) invocations keep working, but they should probably be considered deprecated. I've also added these docs about the method: -------------------------------------------------------- =item copy_if_modified() Takes the file in the C<from> parameter and copies it to the file in the C<to> parameter, or the directory in the C<to_dir> parameter, if the file has changed since it was last copied (or if it doesn't exist in the new location). An optional C<flatten> parameter will copy into C<to_dir> without replicating the directory structure in C<from>; otherwise the entire structure will be copied into C<to_dir>. Any directories that need to be created in order to perform the copying will be automatically created. -------------------------------------------------------- I needed to do this to support the new alternative-layouts stuff I'm about to commit. -Ken |
|
From: Dave R. <au...@ur...> - 2003-05-07 20:09:50
|
On Wed, 7 May 2003, Ken Williams wrote: > > I think making it part of extra_compiler_flags is best. Fewer, simpler > > options for compiling XS seems like a good thing. EU::MM has an > > overwhelming number of them, let's not duplicate that ;) > > Yeah, agreed. I'll do the same thing for 'pollute', which I'd rather > didn't exist in the first place. It's probably not too important nowadays anyway, since it had to do with the 5.005 => 5.6.0 transition. Any module that once needed 'pollute' should have been fixed a while back. -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/ |
|
From: Ken W. <ke...@ma...> - 2003-05-07 20:04:24
|
On Wednesday, May 7, 2003, at 02:55 PM, Dave Rolsky wrote: > On Wed, 7 May 2003, Ken Williams wrote: > >> In the patch that lent support to the INC parameter for pass-through >> Makefile.PLs, we added an 'inc' parameter to M::B. I'm not sure >> that's >> a great idea, because it seems like too brief a name for a somewhat >> obscure parameter (obscure only because most modules don't need to add >> C libraries to the include path anymore in this perl-centric world). >> >> I think we either need to think of a name for it or fold it into the >> new 'extra_compiler_flags' parameter by doing map( "-I$_", @foo ) to >> it. >> >> We can still map INC=... makefile stuff to it properly in the Compat >> code. > > I think making it part of extra_compiler_flags is best. Fewer, simpler > options for compiling XS seems like a good thing. EU::MM has an > overwhelming number of them, let's not duplicate that ;) Yeah, agreed. I'll do the same thing for 'pollute', which I'd rather didn't exist in the first place. -Ken |
|
From: Dave R. <au...@ur...> - 2003-05-07 19:56:51
|
On Wed, 7 May 2003, Ken Williams wrote: > In the patch that lent support to the INC parameter for pass-through > Makefile.PLs, we added an 'inc' parameter to M::B. I'm not sure that's > a great idea, because it seems like too brief a name for a somewhat > obscure parameter (obscure only because most modules don't need to add > C libraries to the include path anymore in this perl-centric world). > > I think we either need to think of a name for it or fold it into the > new 'extra_compiler_flags' parameter by doing map( "-I$_", @foo ) to it. > > We can still map INC=... makefile stuff to it properly in the Compat > code. I think making it part of extra_compiler_flags is best. Fewer, simpler options for compiling XS seems like a good thing. EU::MM has an overwhelming number of them, let's not duplicate that ;) -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/ |
|
From: Ken W. <ke...@ma...> - 2003-05-07 19:53:19
|
Hi Dave, In the patch that lent support to the INC parameter for pass-through Makefile.PLs, we added an 'inc' parameter to M::B. I'm not sure that's a great idea, because it seems like too brief a name for a somewhat obscure parameter (obscure only because most modules don't need to add C libraries to the include path anymore in this perl-centric world). I think we either need to think of a name for it or fold it into the new 'extra_compiler_flags' parameter by doing map( "-I$_", @foo ) to it. We can still map INC=... makefile stuff to it properly in the Compat code. -Ken |
|
From: Ken W. <ke...@ma...> - 2003-05-07 19:48:39
|
On Wednesday, May 7, 2003, at 03:42 AM, ric...@un... via RT wrote: > This message about Module-Build was sent to you by > ric...@un... <ric...@un...> via rt.cpan.org > > Full context and any attached attachments can be found at: > <URL: https://rt.cpan.org/Ticket/Display.html?id=2524 > > > I was porting Devel::LeakTrace, an XS module that links glibc, to > Module::Build and hit some pain. The attached patch helped with the > pain, but it might be tail wagging the dog stuff. I've applied this in a highly modified form, because I did some code cleanup of that area at the same time. Can you try the latest M::B CVS on your Devel::LeakTrace? -Ken |
|
From: Dave R. <au...@ur...> - 2003-05-05 16:26:23
|
Ken, have you looked at this yet? Has anyone else on the list who might know more than more about PPD (i.e. almost anyone ;) looked at it? -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/ |
|
From: Ken W. <ke...@ma...> - 2003-05-05 16:22:46
|
Applied, with a s/TEST_FILE/TEST_FILES/ . -Ken On Saturday, May 3, 2003, at 11:34 AM, Dave Rolsky wrote: > This patch adds support for "pollute" and "inc" parameters. The first > is > only allowed from the command line, because I just assume that module > authors aren't going to specify this in a distro (which may not be a > good > assumption), and the latter is allowed either from the command line or > when creating the M::B object. > > This patch also adds translations for more EU::MM command line > parameters. > Finally, it changes M::B::Compat to just warn if it gets a parameter it > can't translate, as opposed to dying. > > Patch after sig. > > > -dave > > /*======================= > House Absolute Consulting > www.houseabsolute.com > =======================*/ > > > Index: lib/Module/Build/Base.pm > =================================================================== > RCS file: /cvsroot/module-build/Module-Build/lib/Module/Build/Base.pm,v > retrieving revision 1.101 > diff -u -r1.101 Base.pm > --- lib/Module/Build/Base.pm 2 May 2003 22:18:53 -0000 1.101 > +++ lib/Module/Build/Base.pm 3 May 2003 16:33:50 -0000 > @@ -192,6 +192,7 @@ > c_source > autosplit > create_makefile_pl > + pollute > ); > > sub valid_property { exists $valid_properties{$_[1]} } > @@ -1271,7 +1272,9 @@ > > my $coredir = File::Spec->catdir($cf->{archlib}, 'CORE'); > my @include_dirs = $self->{include_dirs} ? map {"-I$_"} > @{$self->{include_dirs}} : (); > + push @include_dirs, $self->split_like_shell($self->{args}{inc}) if > $self->{args}{inc}; > my @ccflags = $self->split_like_shell($cf->{ccflags}); > + push @ccflags, '-DPERL_POLLUTE' if $self->{properties}{pollute} || > $self->{args}{pollute}; > my @optimize = $self->split_like_shell($cf->{optimize}); > $self->do_system($cf->{cc}, @include_dirs, '-c', @ccflags, > @optimize, "-I$coredir", '-o', $obj_file, $file) > or die "error building $cf->{dlext} file from '$file'"; > Index: lib/Module/Build/Compat.pm > =================================================================== > RCS file: > /cvsroot/module-build/Module-Build/lib/Module/Build/Compat.pm,v > retrieving revision 1.17 > diff -u -r1.17 Compat.pm > --- lib/Module/Build/Compat.pm 2 May 2003 22:17:51 -0000 1.17 > +++ lib/Module/Build/Compat.pm 3 May 2003 16:33:50 -0000 > @@ -11,6 +11,12 @@ > ( > PREFIX => 'prefix', > LIB => 'lib', > + UNINST => 'uninst', > + TEST_VERBOSE => 'verbose', > + VERBINST => 'verbose', > + TEST_FILE => 'test_files', > + POLLUTE => 'pollute', > + INC => 'inc', > ); > > sub create_makefile_pl { > @@ -90,7 +96,7 @@ > } elsif (exists $makefile_to_build{$key}) { > push @out, "$makefile_to_build{$key}=$val"; > } else { > - die "Unknown parameter '$key'"; > + warn "Unknown parameter '$key'"; > } > } > return @out; > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Module-build-general mailing list > Mod...@li... > https://lists.sourceforge.net/lists/listinfo/module-build-general > |
|
From: Dave R. <au...@ur...> - 2003-05-03 16:35:34
|
This patch adds support for "pollute" and "inc" parameters. The first is only allowed from the command line, because I just assume that module authors aren't going to specify this in a distro (which may not be a good assumption), and the latter is allowed either from the command line or when creating the M::B object. This patch also adds translations for more EU::MM command line parameters. Finally, it changes M::B::Compat to just warn if it gets a parameter it can't translate, as opposed to dying. Patch after sig. -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/ Index: lib/Module/Build/Base.pm =================================================================== RCS file: /cvsroot/module-build/Module-Build/lib/Module/Build/Base.pm,v retrieving revision 1.101 diff -u -r1.101 Base.pm --- lib/Module/Build/Base.pm 2 May 2003 22:18:53 -0000 1.101 +++ lib/Module/Build/Base.pm 3 May 2003 16:33:50 -0000 @@ -192,6 +192,7 @@ c_source autosplit create_makefile_pl + pollute ); sub valid_property { exists $valid_properties{$_[1]} } @@ -1271,7 +1272,9 @@ my $coredir = File::Spec->catdir($cf->{archlib}, 'CORE'); my @include_dirs = $self->{include_dirs} ? map {"-I$_"} @{$self->{include_dirs}} : (); + push @include_dirs, $self->split_like_shell($self->{args}{inc}) if $self->{args}{inc}; my @ccflags = $self->split_like_shell($cf->{ccflags}); + push @ccflags, '-DPERL_POLLUTE' if $self->{properties}{pollute} || $self->{args}{pollute}; my @optimize = $self->split_like_shell($cf->{optimize}); $self->do_system($cf->{cc}, @include_dirs, '-c', @ccflags, @optimize, "-I$coredir", '-o', $obj_file, $file) or die "error building $cf->{dlext} file from '$file'"; Index: lib/Module/Build/Compat.pm =================================================================== RCS file: /cvsroot/module-build/Module-Build/lib/Module/Build/Compat.pm,v retrieving revision 1.17 diff -u -r1.17 Compat.pm --- lib/Module/Build/Compat.pm 2 May 2003 22:17:51 -0000 1.17 +++ lib/Module/Build/Compat.pm 3 May 2003 16:33:50 -0000 @@ -11,6 +11,12 @@ ( PREFIX => 'prefix', LIB => 'lib', + UNINST => 'uninst', + TEST_VERBOSE => 'verbose', + VERBINST => 'verbose', + TEST_FILE => 'test_files', + POLLUTE => 'pollute', + INC => 'inc', ); sub create_makefile_pl { @@ -90,7 +96,7 @@ } elsif (exists $makefile_to_build{$key}) { push @out, "$makefile_to_build{$key}=$val"; } else { - die "Unknown parameter '$key'"; + warn "Unknown parameter '$key'"; } } return @out; |
|
From: Ken W. <ke...@ma...> - 2003-05-02 22:21:32
|
On Wednesday, April 30, 2003, at 12:16 PM, Dave Rolsky wrote: > On Wed, 30 Apr 2003, Ken Williams wrote: > >> Here's an idea for the Makefile.PL compatibility stuff. I'd like to >> add a new parameter to M::B->new() called 'create_makefile_pl'. Legal >> values for the parameter would be "passthrough" or "traditional", >> which >> would auto-create - you guessed it - pass-through or traditional >> Makefile.PLs during the 'distdir' action (or thereabouts). > > I'm all for the pass-through version, but I think we should discourage > parallel files. If there's problems with the pass-through version, > let's > find them and fix them. I'm not sure we'll always be able to fix the problems in either the pass-through or the traditional versions. Both seem like they'll always have their particular gotchas. -Ken |
|
From: Ken W. <ke...@ma...> - 2003-05-02 22:20:47
|
On Wednesday, April 30, 2003, at 11:31 AM, Ken Williams wrote: > Hey list, > > Here's an idea for the Makefile.PL compatibility stuff. I'd like to > add a new parameter to M::B->new() called 'create_makefile_pl'. Legal > values for the parameter would be "passthrough" or "traditional", > which would auto-create - you guessed it - pass-through or traditional > Makefile.PLs during the 'distdir' action (or thereabouts). This is now checked in to CVS, with tests in t/compat.t and docs in the .pm files. -Ken |
|
From: Michael G S. <sc...@po...> - 2003-05-01 00:16:07
|
On Wed, Apr 30, 2003 at 11:14:47AM -0700, David Carmean wrote:
> With MakeMaker, after considerable pain I was able to figure out how
> to set up a heirarchy of subtrees in which I could work, build, and
> test a particular small set of packages as part of a larger system,
> and not only were the built components placed into the .../blib of the
> top-level, but a make/make test/make install performed at the top of
> any of the subtrees or the top level would recurse and "do the right thing".
>
> The main reason this was attractive was to organize the regression
> tests into small chunks for a kind of a lazy-man's Extreme Programming
> that is my current style. I'm working on an application which uses
> a bunch of modules, some of which I may break out into separate packages;
> I need to be able to test the development version of the app against the
> local copies of these modules without installing them and breaking the
> "installed" copy of the app/libs on the system. But I also don't need/want
> to wait for 100 regression tests to run until these five are passing.
>
> Has anybody else done this, either with MakeMaker or Module::Build?
I'm not entirely sure I understand the question... you want to run programs
off new copies of your modules without installing them to test the apps?
Some simple solutions come to mind:
Run the programs with the blib module to automatically put blib/lib and
blib/arch in @INC. This can be done without editing the programs by
setting the PERL5OPT environment variable to -Mblib
Set the PERL5LIB env manually to /path/to/your/src/blib/lib and blib/arch.
Install your modules into a holding directory using
perl Makefile.PL PREFIX=/holding/dir and set PERL5LIB to the resulting
lib directory.
The latter seems the best since it most closely emulates a real install in
case 'make install' does anything interesting.
--
Cottleston, Cottleston, Cottleston Pie.
A fly can't bird, but a bird can fly.
Ask me a riddle and I reply:
"Cottleston, Cottleston, Cottleston Pie."
|
|
From: David C. <dl...@ha...> - 2003-04-30 18:15:42
|
With MakeMaker, after considerable pain I was able to figure out how to set up a heirarchy of subtrees in which I could work, build, and test a particular small set of packages as part of a larger system, and not only were the built components placed into the .../blib of the top-level, but a make/make test/make install performed at the top of any of the subtrees or the top level would recurse and "do the right thing". The main reason this was attractive was to organize the regression tests into small chunks for a kind of a lazy-man's Extreme Programming that is my current style. I'm working on an application which uses a bunch of modules, some of which I may break out into separate packages; I need to be able to test the development version of the app against the local copies of these modules without installing them and breaking the "installed" copy of the app/libs on the system. But I also don't need/want to wait for 100 regression tests to run until these five are passing. Has anybody else done this, either with MakeMaker or Module::Build? |
|
From: Dave R. <au...@ur...> - 2003-04-30 17:17:27
|
On Wed, 30 Apr 2003, Ken Williams wrote: > Here's an idea for the Makefile.PL compatibility stuff. I'd like to > add a new parameter to M::B->new() called 'create_makefile_pl'. Legal > values for the parameter would be "passthrough" or "traditional", which > would auto-create - you guessed it - pass-through or traditional > Makefile.PLs during the 'distdir' action (or thereabouts). I'm all for the pass-through version, but I think we should discourage parallel files. If there's problems with the pass-through version, let's find them and fix them. -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/ |
|
From: Ken W. <ke...@ma...> - 2003-04-30 16:32:29
|
Hey list, Here's an idea for the Makefile.PL compatibility stuff. I'd like to add a new parameter to M::B->new() called 'create_makefile_pl'. Legal values for the parameter would be "passthrough" or "traditional", which would auto-create - you guessed it - pass-through or traditional Makefile.PLs during the 'distdir' action (or thereabouts). This would have the following benefits: * Helps people who are maintaining both a Makefile.PL and Build.PL, because they wouldn't have to track dependency lists in both places. * Helps people who use a pass-through Makefile.PL, because they wouldn't have to copy-paste from our latest recommendations in the docs. If people have Makefile.PLs that do extra stuff (ask the user questions, sniff around for dependencies, etc.) then we couldn't really help them, but they probably don't want our help anyway if they're managing things that closely. This idea came out of conversation with Chip Salzenberg on IRC the other day. Comments? -Ken |
|
From: Ken W. <ke...@ma...> - 2003-04-29 19:35:57
|
On Tuesday, April 29, 2003, at 02:28 PM, Michael G Schwern wrote: > On Tue, Apr 29, 2003 at 09:59:01AM -0500, Ken Williams wrote: >> A user alerted me to the fact that in lib/Module/Build.pm, I have the >> Cygwin system acting like a variety of Windows rather than a variety >> of >> Unix. He requested that it be changed, so I've done so in CVS. >> Sounds >> good? I'm no Windows dude. > > That's how MakeMaker does it, Cygwin isa Unix. Works out great as > evidenced > by the miniscule size of MM_Cygwin.pm. > Cool, I'll note it in the Changes file then. -Ken |
|
From: Michael G S. <sc...@po...> - 2003-04-29 19:30:55
|
On Tue, Apr 29, 2003 at 09:59:01AM -0500, Ken Williams wrote: > A user alerted me to the fact that in lib/Module/Build.pm, I have the > Cygwin system acting like a variety of Windows rather than a variety of > Unix. He requested that it be changed, so I've done so in CVS. Sounds > good? I'm no Windows dude. That's how MakeMaker does it, Cygwin isa Unix. Works out great as evidenced by the miniscule size of MM_Cygwin.pm. -- michael schwern is |
|
From: Ken W. <ke...@ma...> - 2003-04-29 17:12:14
|
On Tuesday, April 29, 2003, at 07:43 AM, Iain Truskett wrote: > * Greg Matheson (cid...@ma...) [29 Apr 2003 18:22]: > > [...] >> I'm wondering why the only.pm module requires the file to be called >> META.yml rather than META.yaml, despite the fact Module::Build >> documentation says it is called META.yaml and the other YAML files >> that the only module creates have the .yaml extension. > > It was renamed from META.yaml to META.yml to aid systems that have > trouble with more than 3 characters in a suffix. > > The references to META.yaml in the documentation are errors. I've patched this in CVS. Thanks for the report. Greg, the docs & code in Module::Build have been out of sync for a while - it's been created as META.yml for several releases now. That name should be considered stable. -Ken |
|
From: Ken W. <ke...@ma...> - 2003-04-29 14:59:09
|
Hey, A user alerted me to the fact that in lib/Module/Build.pm, I have the Cygwin system acting like a variety of Windows rather than a variety of Unix. He requested that it be changed, so I've done so in CVS. Sounds good? I'm no Windows dude. -Ken |
|
From: Iain T. <tmd...@de...> - 2003-04-29 12:44:28
|
* Greg Matheson (cid...@ma...) [29 Apr 2003 18:22]: [...] > I'm wondering why the only.pm module requires the file to be called > META.yml rather than META.yaml, despite the fact Module::Build > documentation says it is called META.yaml and the other YAML files > that the only module creates have the .yaml extension. It was renamed from META.yaml to META.yml to aid systems that have trouble with more than 3 characters in a suffix. The references to META.yaml in the documentation are errors. cheers, -- Iain. |
|
From: Greg M. <cid...@ma...> - 2003-04-29 08:20:07
|
Oops. My reverse_name setting doesn't seem to be working. Here I go again: I'm wondering why the only.pm module requires the file to be called META.yml rather than META.yaml, despite the fact Module::Build documentation says it is called META.yaml and the other YAML files that the only module creates have the .yaml extension. Trying out Module::Build on modules which ship with Makefile.PL, I found ./Build distdir was a way to create this file, without which ./Build versioninstall wouldn't work. -- Greg Matheson Taiwan |
|
From: Greg M. <la...@ms...> - 2003-04-29 07:44:11
|
I'm wondering why the only.pm module requires the file to be called META.yml rather than META.yaml, despite the fact Module::Build documentation says it is called META.yaml and all the other YAML files that the only module creates have the .yaml extension. Trying out Module::Build on modules which ship with Makefile.PL, I found ./Build distdir was the way to create this file, without which ./Build versioninstall wouldn't work. -- Greg Matheson Taiwan |
|
From: Ken W. <ke...@ma...> - 2003-04-28 19:41:45
|
On Saturday, April 26, 2003, at 11:34 AM, Dave Rolsky wrote: > The current code only adds these to the cleanup if they are not up to > date, but if for some reason they already exist and are up to date, > they > should still be removed on cleanup. > > Patch below sig. I'm not sure exactly how to test this though. Applied. -Ken |
|
From: <do...@ha...> - 2003-04-27 21:16:09
|
On Sun, Apr 27, 2003 at 10:05:19PM +0100, Dominic Mitchell wrote: > Oh, one last question. Is there an archive of the module-build-general > list anywhere? Sourceforge doesn't seem to know about it. My apologies; it appears to be back on line now. -Dom |
|
From: Dominic M. <do...@ha...> - 2003-04-27 21:05:28
|
I've got a .PL file that I'm trying to get run as part of my build.
Module::Build->new(
module_name => 'MyModule',
PL_files => {
'lib/mkconst.PL' => [],
},
);
However, the mkconst.PL script is not getting run at all. The docs
appear to indicate that it would get run, and that there would be
nothing to clean up, based on what I've specified. Is that right?
Looking at process_PL_files(), it would seem that things only get run if
there's something in the list.
However, taking a step or two back....
What I'm trying to do is rebuild the file lib/Constants.pm from
lib/Constants.pm.in only if it's out of date. Using
ExtUtils::MakeMaker, this was (relatively) easy. What's the best way to
do this using Module::Build? I started looking at .PL files to sort it
out, but I don't think that's the right answer. Would it be better to
subclass Module::Build and override ACTION_build to do the right thing?
I haven't even started looking at getting the SWIG bits of this module
working yet...
Oh, one last question. Is there an archive of the module-build-general
list anywhere? Sourceforge doesn't seem to know about it.
Thanks,
-Dom
|
7 messages has been excluded from this view by a project administrator.
