module-build-general Mailing List for Module::Build (Page 162)
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: Steve P. <sp...@qu...> - 2003-08-01 00:14:09
|
On Thursday, July 31, 2003, at 07:32 pm, Steve Purkis wrote: > I suppose it's worth asking this: why not use version objects? Because they don't come standard with most (any?) versions of perl is one reason. > Which works for most things. I think it break because of how perl > does SV -> NV conversions [1]: > > '0.03_01' > '0.03' == false The attached patch fixes this. It doesn't do everything that version.pm does, but I imagine it can be integrated easily if need be. -Steve |
|
From: Steve P. <sp...@qu...> - 2003-07-31 23:35:37
|
On Thursday, July 24, 2003, at 07:34 pm, Mike Castle wrote: > > My normal install process for installing perl modules is: > > perl Makefile.PL > make > su - > make install > > > Now, for most systems, this is ok, but for module-build, the make > install > step is where the man pages get created, and so they get created as > root. > > So when I go to delete the directory afterwards, I can't. Well, you could just do: % sudo make clean but agreed - very annoying. To fix it you could make 'build' dispatch to 'builddocs', but that would be bad seeing as 'builddocs' should (but doesn't for some reason?) depend on 'build', which means an infinite loop. So maybe the best idea is to take the common code out of 'builddocs' and call it from both actions, and fix the dependency issue? -Steve |
|
From: Steve P. <sp...@qu...> - 2003-07-31 23:18:18
|
Hiya, I've whipped up a patch using the newly documented up_to_date() (ta for pointing it out, Dave) to make the 'builddocs' action skip pod2man generation if the output file looks up to date. -Steve |
|
From: Steve P. <sp...@qu...> - 2003-07-31 18:43:38
|
On Tuesday, July 29, 2003, at 06:57 pm, Ken Williams wrote: > but mixing the two, i.e. > > perl Makefile.PL > ... > Build realclean > > will leave an orphan Makefile around. > > As for a fix, it's probably not a great idea to remove the Makefile > when doing 'Build realclean', but maybe the subsequent failure modes > could be cleaned up a bit. Don't see why the Makefile shouldn't be removed by 'Build realclean' - unless it's been modified or is not part of the project. But it would be easy enough to scan it for some auto-generated text before deleting. At any rate, I'm easy either way - if 'make realclean' checks for Build before trying to run it, that works for me. In fact, it might be an idea for all the targets to do that? On second thought, does it really matter if the Makefile dies gracefully or not in this situation? -Steve |
|
From: Steve P. <sp...@qu...> - 2003-07-31 18:41:50
|
On Tuesday, July 29, 2003, at 08:48 pm, Ken Williams wrote:
> On Tuesday, July 29, 2003, at 06:00 AM, Steve Purkis wrote:
>
>> [snip - version bug]
>
> Good catch. The version comparison stuff probably needs some work,
> and I'm not sure I'm completely up-to-date on the Totally Correct way
> to compare version numbers/strings. Do you know much about this?
I'm not too up-to-date on them either, I'm afraid. But I reckon John
Peacock's version.pm would be a good place to start.
I suppose it's worth asking this: why not use version objects?
> (By the way, you probably should use 'build_requires' rather than
> 'requires' for the Module::Build dependency. I'm sure that has the
> same bug, though.)
Yup, that was for sake of argument. Still happens when you use
'build_requires'..
Further investigation leads me to an eval() in
M::B::Base->check_installed_status:
...
unless (eval "\$status{have} $op \$version") {
...
Which works for most things. I think it break because of how perl does
SV -> NV conversions [1]:
'0.03_01' > '0.03' == false
Because '0.03_01' is converted to 0.03. But:
0.03_01 > 0.03 == true
Because 0.03_01 is really 0.0301.
-Steve
[1] - I don't remember if this has changed over the last versions of
perl...
|
|
From: Ken W. <ke...@ma...> - 2003-07-30 14:35:34
|
On Wednesday, July 30, 2003, at 09:08 AM, Mathieu Arnold wrote: > +-le 22/07/2003 14:54 -0500, Ken Williams =E9crivait : > | > | Hmm, can't really tell what's going wrong. It's possible that -T=20 > isn't > | working correctly on 5.005. If you can try the current CVS when it > | becomes available, I've made some changes in t/manifypods.t that=20 > should > | give some more diagnostic information upon failure. My hunch is = that > | contains_pod() isn't working correctly. > > Ok, here is a patch which makes it work... > contains_pod does work, it's File::Find that's wront...... > > Don't ask why, but it does its job now. Thanks Mathieu, looks like $File::Find::name isn't to be trusted on old=20= perls. I've applied the patch, should work fine since the -T test is in there=20= now too. -Ken |
|
From: Mathieu A. <m...@ab...> - 2003-07-30 14:09:05
|
+-le 22/07/2003 14:54 -0500, Ken Williams =E9crivait : |=20 | Hmm, can't really tell what's going wrong. It's possible that -T isn't | working correctly on 5.005. If you can try the current CVS when it | becomes available, I've made some changes in t/manifypods.t that should | give some more diagnostic information upon failure. My hunch is that | contains_pod() isn't working correctly. Ok, here is a patch which makes it work... contains_pod does work, it's File::Find that's wront...... Don't ask why, but it does its job now. --=20 Mathieu Arnold |
|
From: Ken W. <ke...@ma...> - 2003-07-29 20:09:05
|
On Tuesday, July 29, 2003, at 06:00 AM, Steve Purkis wrote:
> Hiya,
>
> I get an error when trying to require a development version of a
> module, for example:
>
> Module::Build->new(
> ...
> requires => { 'Module::Build' => '0.19_03' }
> );
>
> This results in the following when I try to create a build script
> w/M::B 0.19_01 installed:
>
> ...
> Argument "0.19_03" isn't numeric in numeric ge (>=) at (eval 29) line
> 1.
> Argument "0.19_01" isn't numeric in numeric ge (>=) at (eval 29) line
> 1.
>
> Moreover, it *doesn't* print out an 'ERROR: ...' line, as expected.
> This doesn't go away after I install 0.19_03.
Good catch. The version comparison stuff probably needs some work, and
I'm not sure I'm completely up-to-date on the Totally Correct way to
compare version numbers/strings. Do you know much about this?
(By the way, you probably should use 'build_requires' rather than
'requires' for the Module::Build dependency. I'm sure that has the
same bug, though.)
-Ken
|
|
From: Ken W. <ke...@ma...> - 2003-07-29 18:02:01
|
On Tuesday, July 29, 2003, at 07:00 AM, Steve Purkis wrote: > Hiya, > > Another small bug: running ./Build realclean in a Makefile.PL > passthrough situation doesn't get rid of the Makefile. Running 'make > realclean' thereafter fails. Dunno if it's worth fixing... Yeah, the expectation is that the user will do *either* perl Makefile.PL make ... make realclean *or* perl Build.PL Build ... Build realclean but mixing the two, i.e. perl Makefile.PL ... Build realclean will leave an orphan Makefile around. As for a fix, it's probably not a great idea to remove the Makefile when doing 'Build realclean', but maybe the subsequent failure modes could be cleaned up a bit. -Ken |
|
From: Steve P. <sp...@qu...> - 2003-07-29 12:00:32
|
Hiya, Another small bug: running ./Build realclean in a Makefile.PL passthrough situation doesn't get rid of the Makefile. Running 'make realclean' thereafter fails. Dunno if it's worth fixing... -Steve |
|
From: Steve P. <sp...@qu...> - 2003-07-29 11:03:05
|
Hiya,
I get an error when trying to require a development version of a
module, for example:
Module::Build->new(
...
requires => { 'Module::Build' => '0.19_03' }
);
This results in the following when I try to create a build script
w/M::B 0.19_01 installed:
...
Argument "0.19_03" isn't numeric in numeric ge (>=) at (eval 29) line
1.
Argument "0.19_01" isn't numeric in numeric ge (>=) at (eval 29) line
1.
Moreover, it *doesn't* print out an 'ERROR: ...' line, as expected.
This doesn't go away after I install 0.19_03.
-Steve
|
|
From: Ken W. <ke...@ma...> - 2003-07-29 02:25:55
|
On Monday, July 28, 2003, at 04:32 PM, Dave Rolsky wrote: > --- lib/Module/Build.pm 25 Jul 2003 14:17:34 -0000 1.91 > +++ lib/Module/Build.pm 28 Jul 2003 21:31:35 -0000 > @@ -802,6 +802,11 @@ > The arguments may be either a scalar or an array reference of file > names. > > +=item contains_pod($file) > + > +Returns true if the given file appears contains a line beginning with > +'=pod', '=head', or '=item'. > + I think you forgot something in the middle there. Here's how I'm patching: --- lib/Module/Build.pm 25 Jul 2003 14:17:34 -0000 1.91 +++ lib/Module/Build.pm 29 Jul 2003 02:23:35 -0000 @@ -802,6 +802,13 @@ The arguments may be either a scalar or an array reference of file names. +=item contains_pod($file) + +Returns true if the given file appears to contain POD documentation. +Currently this checks whether the file has a line beginning with +'=pod', '=head', or '=item', but the exact semantics may change in the +future. + =back -Ken |
|
From: Ken W. <ke...@ma...> - 2003-07-29 02:10:01
|
On Monday, July 28, 2003, at 01:23 PM, Dave Rolsky wrote: > The docs say it takes an array reference, but it really wants a plain > old > array. > The new() parameter 'add_to_cleanup' takes an array reference, and the add_to_cleanup() method takes a list. -Ken |
|
From: Dave R. <au...@ur...> - 2003-07-28 22:49:25
|
On Mon, 28 Jul 2003, Dave Rolsky wrote: > Bleah, that sucks! Whoever wrote EU::Manifest needs to be beaten. > > Anyway, Ken, how do you feel about changing line 1414 from > > ExtUtils::Manifest::manicopy($dist_files, $dist_dir, 'best'); > > to > > ExtUtils::Manifest::manicopy($dist_files, $dist_dir, 'cp'); > > Otherwise I can't munge stuff in the dist dir, because I'm actually > munging stuff in the real base dir, which is _really_ annoying. Here's a good one. If you set the copying method to 'cp' it changes the permissions on the copied files to remove write permission. Just brilliant, really. After all, it's inconceivable that anyone might need to ever alter these files. Grr.... This I can work around, I guess. -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/ |
|
From: Dave R. <au...@ur...> - 2003-07-28 22:45:59
|
Bleah, that sucks! Whoever wrote EU::Manifest needs to be beaten. Anyway, Ken, how do you feel about changing line 1414 from ExtUtils::Manifest::manicopy($dist_files, $dist_dir, 'best'); to ExtUtils::Manifest::manicopy($dist_files, $dist_dir, 'cp'); Otherwise I can't munge stuff in the dist dir, because I'm actually munging stuff in the real base dir, which is _really_ annoying. -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/ |
|
From: Dave R. <au...@ur...> - 2003-07-28 21:33:53
|
It's pretty handy, might as well document it. -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/ Index: lib/Module/Build.pm =================================================================== RCS file: /cvsroot/module-build/Module-Build/lib/Module/Build.pm,v retrieving revision 1.91 diff -u -r1.91 Build.pm --- lib/Module/Build.pm 25 Jul 2003 14:17:34 -0000 1.91 +++ lib/Module/Build.pm 28 Jul 2003 21:31:35 -0000 @@ -802,6 +802,11 @@ The arguments may be either a scalar or an array reference of file names. +=item contains_pod($file) + +Returns true if the given file appears contains a line beginning with +'=pod', '=head', or '=item'. + =back =head1 ACTIONS |
|
From: Dave R. <au...@ur...> - 2003-07-28 18:24:41
|
The docs say it takes an array reference, but it really wants a plain old array. -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/ |
|
From: Ken W. <ke...@ma...> - 2003-07-28 02:56:47
|
On Sunday, July 27, 2003, at 07:45 PM, Randy Kobes wrote:
> On Sun, 27 Jul 2003, Ken Williams wrote:
>
>> Hi DH,
>>
>> Thanks for the report. I guess Win32 systems don't typically install
>> man pages. Just to make sure I understand the problem, your Config.pm
>> doesn't define values for these variables, right?
>>
>> $Config{installsiteman1dir}
>> $Config{installman1dir}
>> $Config{installsiteman3dir}
>> $Config{installman3dir}
>>
>> I just checked in a patch to skip building & installing man pages when
>> these variables don't exist.
>
> Hi Ken,
> You might want to skip the man pages entirely on Win32 - on
> my system, I have these variables defined, but man pages won't
> install, as typically they contain ':' in their names, and Win32
> refuses to create a file with ':' in the name.
Steve Purkis, who supplied the patch for manpage generation, defined
the manpage separator as '::' on Unix, but '.' on Win32 (and '__' on
VMS, for those keeping score). I think the intention was to solve the
problem you mention.
-Ken
|
|
From: Ken W. <ke...@ma...> - 2003-07-25 14:18:52
|
On Thursday, July 24, 2003, at 11:15 PM, Dave Rolsky wrote: > This method is obviously useful for people writing customized build > processes, and should be documented, because otherwise everyone will > write > their own ;) > Applied! -Ken |
|
From: Ken W. <ke...@ma...> - 2003-07-25 14:16:05
|
On Thursday, July 24, 2003, at 11:06 PM, Dave Rolsky wrote: > The patch, after my sig, includes the following: > > - Update list of actions in POD, and include some docs for ppd and > distmeta actions. > > - Document dist_author, dist_abstract, and codebase arguments to new(). > > - Remove an unused method from PPMMaker. > > Patch after sig. Applied! -Ken |
|
From: Dave R. <au...@ur...> - 2003-07-25 04:16:05
|
This method is obviously useful for people writing customized build processes, and should be documented, because otherwise everyone will write their own ;) -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/ Index: Build.pm =================================================================== RCS file: /cvsroot/module-build/Module-Build/lib/Module/Build.pm,v retrieving revision 1.89 diff -u -u -r1.89 Build.pm --- Build.pm 24 Jul 2003 19:22:36 -0000 1.89 +++ Build.pm 25 Jul 2003 04:14:03 -0000 @@ -766,6 +790,18 @@ because the C<Build> script will C<chdir()> into this directory as soon as it begins execution. +=item up_to_date($source_file, $derived_file) + +=item up_to_date(\@source_files, \@derived_files) + +This method can be used to compare a set of source files to a set of +derived files. If any of the source files are newer than any of the +derived files, it returns false. Additionally, if any of the derived +files do not exist, it returns false. Otherwise it returns true. + +The arguments may be either a scalar or an array reference of file +names. + =back =head1 ACTIONS |
|
From: Dave R. <au...@ur...> - 2003-07-25 04:07:24
|
The patch, after my sig, includes the following: - Update list of actions in POD, and include some docs for ppd and distmeta actions. - Document dist_author, dist_abstract, and codebase arguments to new(). - Remove an unused method from PPMMaker. Patch after sig. -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/ ? mb-patch ? t/Sample/SIGNATURE ? t/Sample/Sample-0.01.tar.gz Index: lib/Module/Build.pm =================================================================== RCS file: /cvsroot/module-build/Module-Build/lib/Module/Build.pm,v retrieving revision 1.89 diff -u -r1.89 Build.pm --- lib/Module/Build.pm 24 Jul 2003 19:22:36 -0000 1.89 +++ lib/Module/Build.pm 25 Jul 2003 04:05:11 -0000 @@ -133,16 +133,17 @@ 'actions'. In this case the actions run are 'build' (the default action), 'test', and 'install'. Actions defined so far include: - build help - clean install - diff manifest - dist manifypods - distcheck realclean - distclean skipcheck - distdir test - distsign testdb - disttest versioninstall - fakeinstall + build fakeinstall + builddocs help + clean install + diff manifest + dist ppd + distcheck realclean + distclean skipcheck + distdir test + distmeta testdb + distsign versioninstall + disttest You can run the 'help' action for a complete list of actions. @@ -542,6 +543,29 @@ extra_linker_flags => `glib-config --libs`, ); +=head dist_author + +This should be something like "John Doe <jd...@ex...>". This is +used when creating PPD files. If this is not specified, then +C<Module::Build> looks at the module from which it gets the +distribution's version. If it finds a POD section marked "=head1 +AUTHOR", then it uses the contents of this section. + +=head dist_abstract + +This should be a short description of the distribution. This is used +when creating PPD files. If it is not given then C<Module::Build> +looks in the POD of the module from which it gets the distribution's +version. It looks for the first line matching C<$package\s-\s(.+)>, +and uses the captured text as the abstract. + +=head codebase + +This can be either a single scalar string, or an array reference of +strings. It is required when creating PPD files. It should be a URL, +or URLs, to be used as the value for the C<< <CODEBASE> >> tag in the +generated PPD. + =back =item create_build_script() @@ -994,6 +1018,10 @@ Uses C<Module::Signature> to create a SIGNATURE file for your distribution. +=item distmeta + +Creates the F<META.yml> file for your distribution. + =item distcheck Reports which files are in the build directory but not in the @@ -1029,6 +1057,10 @@ Performs the 'distdir' action, then switches into that directory and runs a C<perl Build.PL>, followed by the 'build' and 'test' actions in that directory. + +=item ppd + +Build a PPD file for your distribution. =back Index: lib/Module/Build/PPMMaker.pm =================================================================== RCS file: /cvsroot/module-build/Module-Build/lib/Module/Build/PPMMaker.pm,v retrieving revision 1.1 diff -u -r1.1 PPMMaker.pm --- lib/Module/Build/PPMMaker.pm 10 May 2003 17:40:13 -0000 1.1 +++ lib/Module/Build/PPMMaker.pm 25 Jul 2003 04:05:12 -0000 @@ -104,18 +104,6 @@ return $ppd_file; } -sub _parse_abstract { - my($self, $file) = @_; - - my $result; - local $/ = "\n"; - - my $fh = IO::File->new("<$file") - or die "Could not open $file: $!"; - - return $result; -} - sub _ppd_version { my ($self, $version) = @_; |
|
From: Dave R. <au...@ur...> - 2003-07-24 19:57:44
|
On Thu, 24 Jul 2003, Ken Williams wrote: > Let me know if you have feedback about it. This looks great. I can definitely use this for the Alzabo tests. -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/ |
|
From: Ken W. <ke...@ma...> - 2003-07-24 19:51:59
|
Hi,
I've released a new beta to CPAN and sourceforge
(https://sourceforge.net/projects/module-build/)
There's really just one entry in the changelog since 0.19_02:
- Added a notes() feature, which helps share data transparently
between the Build.PL and t/*.t scripts. (XXX needs documentation)
This is really a cool feature, actually. Here's how it's used:
------ in Build.PL ---------------
$m->notes(foo => 'bar'); # Set a notes() entry
------ later, in t/notes.t --------------
use Module::Build;
my $m = Module::Build->instance;
my $value = $m->notes('foo'); # Retrieves notes() entry 'bar'
I use Data::Dumper to store the keys & values, so pretty much any data
can be shared in this way.
I haven't documented it yet because I'm not completely sure about the
interfaces yet. I really like the idea of the instance() method, but
I'm not sure this is the right name because it's not a singleton class.
Maybe current() or something. And there may have to be some caveats
about the fact that this object isn't exactly the same object as the
one created in the Build script, though for most purposes it should be
close enough.
Alternatively, I could get notes() to work as a class method, but
currently it doesn't. I think that would probably be a kludge anyway,
it wouldn't really know the values of the config variables that need to
be in the $m object.
Let me know if you have feedback about it.
-Ken
|
|
From: Mike C. <da...@ix...> - 2003-07-24 18:34:47
|
My normal install process for installing perl modules is:
perl Makefile.PL
make
su -
make install
Now, for most systems, this is ok, but for module-build, the make install
step is where the man pages get created, and so they get created as root.
So when I go to delete the directory afterwards, I can't.
Very annoying.
Please adjust.
mrc
--
Mike Castle da...@ix... www.netcom.com/~dalgoda/
We are all of us living in the shadow of Manhattan. -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc
|
7 messages has been excluded from this view by a project administrator.
