Thread: [Module::Build] Making 0.28 a reality
Status: Beta
Brought to you by:
kwilliams
Menu
▾
▴
module-build-general
|
From: John P. <jpe...@ro...> - 2006-02-18 02:57:42
|
Folks -
What can I do to help get 0.28 out the door. I was using 0.27_07 and released
version-0.54 to CPAN and promptly broke every module trying to upgrade that
depends on version due to a limitation in 0.2611. It seems that
have_c_compiler() depends on _build/ existing, yet _build/ isn't created until
you call create_build_script() which I wasn't doing until after I found out
whether there was a compiler available. Chicken <=> Egg. Needless to say,
version-0.55 is out now. :(
I know, *my fault*, not Module::Build's, but still, it makes me want to use
Module::Install now... ;-)
Where we left the earlier discussion was that the version.pm patch to M::B would
require upgrading the YAML dependency to 0.58. The issue was that this would
[mostly] silently disable the YAML support for people who didn't notice. There
seems to be two ways around it:
1) write a routine to query the user whether they wanted to upgrade YAML at the
same time and then make it a prereq;
or
2) just go ahead and make YAML a prereq of 0.28.
Is there any reason why #2 isn't the way to go? Is M::B really wedded to the
_write_minimal_metadata code for some reason? Isn't YAML stable enough? YAML
doesn't appear to have any non-core dependencies (according to module_info):
Modules used:
YAML::Base
YAML::Dumper::Base
YAML::Node
base
constant
strict
warnings
That would certainly be the cleanest way to deal with it.
As a third option, if I had to, I could produce a patch that would force the
version objects to stringify before being added to the YAML $node. But this is
especially ugly and hackish.
Note also that I forgot this on my previous patch:
$ svk diff lib/Module/Build/Base.pm
=== lib/Module/Build/Base.pm
==================================================================
--- lib/Module/Build/Base.pm (revision 1830)
+++ lib/Module/Build/Base.pm (local)
@@ -1090,10 +1090,6 @@
my $self = shift;
my ($v1, $op, $v2) = @_;
- # for alpha versions - this doesn't cover all cases, but should work for most:
- $v1 =~ s/_(\d+)\z/$1/;
- $v2 =~ s/_(\d+)\z/$1/;
-
my $eval_str = "\$v1 $op \$v2";
my $result = eval $eval_str;
$self->log_warn("error comparing versions: '$eval_str' $@") if $@;
since version objects work fine as alpha versions. After 0.28 is out, I can
move more of the version code to Module::Build::version and simplify a lot of
code in the process.
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: <and...@fr...> - 2006-02-18 11:35:41
|
>>>>> On Fri, 17 Feb 2006 21:57:57 -0500, John Peacock <jpe...@ro...> said: > I know, *my fault*, not Module::Build's, but still, it makes me want to use > Module::Install now... ;-) Would using "./Build disttest" have uncovered the bug? -- andreas |
|
From: John P. <jpe...@ro...> - 2006-02-18 14:57:43
|
Andreas J. Koenig wrote: >>>>>> On Fri, 17 Feb 2006 21:57:57 -0500, John Peacock <jpe...@ro...> said: > > > I know, *my fault*, not Module::Build's, but still, it makes me want to use > > Module::Install now... ;-) > > Would using "./Build disttest" have uncovered the bug? > No, because I had M::B 0.27_07 installed, which doesn't have this limitation (and actually I use Module::Release, so `make disttest` _was_ run). 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: Julian M. <ju...@me...> - 2006-02-18 12:55:11
|
John Peacock wrote: > Where we left the earlier discussion was that the version.pm patch to > M::B would require upgrading the YAML dependency to 0.58. The issue was > that this would [mostly] silently disable the YAML support for people > who didn't notice. There seems to be two ways around it: > > 1) write a routine to query the user whether they wanted to upgrade YAML > at the same time and then make it a prereq; > > or > > 2) just go ahead and make YAML a prereq of 0.28. > > Is there any reason why #2 isn't the way to go? That would require YAML on _every_ Module::Build installation of the world,= =20 not just on module authors' systems. E.g. if I wanted to install (not=20 repackage) version.pm, I'd have to install YAML first. |
|
From: Rob K. <rob...@gm...> - 2006-02-18 13:02:10
|
On 2/18/06, Julian Mehnle <ju...@me...> wrote: > That would require YAML on _every_ Module::Build installation of the worl= d, > not just on module authors' systems. E.g. if I wanted to install (not > repackage) version.pm, I'd have to install YAML first. So? Perl requires MLDBM on every Perl installation in the world. How many times has anyone on this list used that module? Buehler .... Buehler .... Prereqs are the name of the game in Perl. Minimizing them is a nice to have, but YAML is rapidly becoming the better XML (which I'm grateful for) and I'm not sure "forcing" people to install YAML is a bad plan. Rob |
|
From: Julian M. <ju...@me...> - 2006-02-18 13:10:32
|
Rob Kinyon wrote: > On 2/18/06, Julian Mehnle <ju...@me...> wrote: > > That would require YAML on _every_ Module::Build installation of the > > world, not just on module authors' systems. E.g. if I wanted to > > install (not repackage) version.pm, I'd have to install YAML first. > > So? Perl requires MLDBM on every Perl installation in the world. How > many times has anyone on this list used that module? Buehler .... > Buehler .... > > Prereqs are the name of the game in Perl. Minimizing them is a nice to > have, but YAML is rapidly becoming the better XML (which I'm grateful > for) and I'm not sure "forcing" people to install YAML is a bad plan. _I_, for that matter, certainly wouldn't have anything against having YAML= =20 in core, which is what would have to happen if M::B will be going into=20 core. But you should probably go convince the core people first. |
|
From: Yitzchak Scott-T. <sth...@ef...> - 2006-02-19 06:38:14
|
Maybe I'm changing the topic a little, but *why* are you making version dependent on Module::Build? I don't like the idea of requiring YAML for non-module-authors at all. Maybe you could look more into declaring a version::yaml_dump routine that might work for YAML 0.3[5-9]? I'm sure the YAML people would be glad to give pointers. |
|
From: John P. <jpe...@ro...> - 2006-02-19 15:31:02
|
Yitzchak Scott-Thoennes wrote:
> Maybe I'm changing the topic a little, but *why* are you making
> version dependent on Module::Build?
Reverse that. We are trying to make Module::Build use version.pm for all of its
internal version comparisons.
> I don't like the idea of requiring YAML for non-module-authors at all.
> Maybe you could look more into declaring a version::yaml_dump routine
> that might work for YAML 0.3[5-9]? I'm sure the YAML people would be
> glad to give pointers.
I tried that and could get YAML to call the version::yaml_dump routine. I'd be
happy to go that route if someone could tell me how to do it. YAML pre-0.50
didn't handle objects very well (lots of warnings and malformed output). And
unlike one would expect, YAML didn't just do $obj->can('yaml_dump') and then
call the routine, it just bullies along and dumps version objects weirdly.
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: Yitzchak Scott-T. <sth...@ef...> - 2006-02-19 17:09:56
|
On Sun, Feb 19, 2006 at 10:31:15AM -0500, John Peacock wrote: > Yitzchak Scott-Thoennes wrote: > > Maybe I'm changing the topic a little, but *why* are you making > > version dependent on Module::Build? > > Reverse that. We are trying to make Module::Build use version.pm > for all of its internal version comparisons. No, I meant the question I asked. I went to install version to try to play with yaml_dump, and was really surprised at the dependency. |
|
From: John P. <jpe...@ro...> - 2006-02-19 19:26:46
|
Yitzchak Scott-Thoennes wrote: > No, I meant the question I asked. I went to install version to try to > play with yaml_dump, and was really surprised at the dependency. version uses Module::Build for its installer. How can it not be dependent on M::B? Or are you another person wondering why I would abandon the wonderful EU::MM API. 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: Yitzchak Scott-T. <sth...@ef...> - 2006-02-19 19:39:17
|
On Sun, Feb 19, 2006 at 02:27:02PM -0500, John Peacock wrote: > Yitzchak Scott-Thoennes wrote: > > No, I meant the question I asked. I went to install version to try to > > play with yaml_dump, and was really surprised at the dependency. > > version uses Module::Build for its installer. How can it not be dependent on > M::B? Or are you another person wondering why I would abandon the wonderful > EU::MM API. Yes. I'm not saying you should stick with EU::MM, I'd just like to know why you aren't. |
|
From: John P. <jpe...@ro...> - 2006-02-19 21:35:55
|
Yitzchak Scott-Thoennes wrote: > Yes. I'm not saying you should stick with EU::MM, I'd just like to > know why you aren't. A) I'm moving all of my modules to M::B (only Math::FixedPrecision is left); B) I've been using M::B with version.pm since May 2005 and (apart from recent $author precipitated failures) no one has complained (except for AdamK, which seems to be at least partly philosophical in nature). I don't want to go through the hassle of subclassing EU::MM to perform the kind of sophisticated build behavior that I'm trying to do (so far unsuccessfully) with version.pm (vis automatically choose the pure Perl or XS mode). 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: Yitzchak Scott-T. <sth...@ef...> - 2006-02-19 17:45:48
|
On Sun, Feb 19, 2006 at 10:31:15AM -0500, John Peacock wrote: > Yitzchak Scott-Thoennes wrote: > > Maybe I'm changing the topic a little, but *why* are you making > > version dependent on Module::Build? > > Reverse that. We are trying to make Module::Build use version.pm for all of its > internal version comparisons. > > > I don't like the idea of requiring YAML for non-module-authors at all. > > Maybe you could look more into declaring a version::yaml_dump routine > > that might work for YAML 0.3[5-9]? I'm sure the YAML people would be > > glad to give pointers. > > I tried that and could get YAML to call the version::yaml_dump routine. Do you mean couldn't? |
|
From: John P. <jpe...@ro...> - 2006-02-19 19:26:25
|
Yitzchak Scott-Thoennes wrote: > On Sun, Feb 19, 2006 at 10:31:15AM -0500, John Peacock wrote: >> I tried that and could get YAML to call the version::yaml_dump routine. > > Do you mean couldn't? Yes (new keyboard). YAML-0.39 doesn't automatically call version::yaml_dump() and I could not read the invisible documentation on how to use Bless() to cause yaml_dump to be executed. Example code welcome... 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: Yitzchak Scott-T. <sth...@ef...> - 2006-02-19 06:44:34
|
On Fri, Feb 17, 2006 at 09:57:57PM -0500, John Peacock wrote: > What can I do to help get 0.28 out the door. I was using 0.27_07 and released > version-0.54 to CPAN and promptly broke every module trying to upgrade that > depends on version due to a limitation in 0.2611. It seems that > have_c_compiler() depends on _build/ existing, yet _build/ isn't created until > you call create_build_script() which I wasn't doing until after I found out > whether there was a compiler available. Chicken <=> Egg. Needless to say, > version-0.55 is out now. :( FWIW, I just tried a stock cygwin perl (with no additional modules installed), installed Module-Build 0.27_07, and tried to install version-0.55 and got: $ 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. $ perl Makefile.PL # running Build.PL /usr/bin/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. Couldn't run Build.PL: Bad address at /usr/lib/perl5/site_perl/5.8/Module/Build/Compat.pm line 198. |
|
From: John P. <jpe...@ro...> - 2006-02-19 16:40:17
|
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! Expect version-0.56 RSN (with a completely new installer written in Python). :( 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: Yitzchak Scott-T. <sth...@ef...> - 2006-02-19 17:08:27
|
On Sun, Feb 19, 2006 at 11:40:29AM -0500, 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! > > Expect version-0.56 RSN (with a completely new installer written in Python). :( It was my understanding that 0.27_* no longer directly check for a C-compiler, but depend on ExtUtils::CBuilder doing the check. So you need that as an additional pre-Build.PL/Makefile.PL requirement. And (as has already been discussed ad nauseam) there is no such thing as a way to list a pre-Build.PL/Makefile.PL requirement (except with newer tools that read META.yml iff you have YAML installed). Though I see a message[*] from Ken that he apparently intends to fix this. I have no idea how he'd go about this, though. * http://nntp.perl.org/group/perl.perl5.porters/109856 |
|
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: Stephen A. <spa...@gm...> - 2006-02-19 21:52:02
|
... > And (as has already been discussed ad nauseam) there is no such thing > as a way to list a pre-Build.PL/Makefile.PL requirement (except with > newer tools that read META.yml iff you have YAML installed). > Though I see a message[*] from Ken that he apparently intends to fix this= . > I have no idea how he'd go about this, though. ... It has already been stated that the subset of the YAML specification actual= ly 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? 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 imagi= ne others could write it too and not have to wait for me.) Stephen |
|
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: Stephen A. <spa...@gm...> - 2006-03-20 04:05:06
|
> > If people thought this was a good idea (and the solution to some of the=
se
> > problems), I would be happy to write it.
...
> That would be awesome.
...
> -Ken
Hi,
Ken said this would be useful, so I am ready to submit a patch.
I have modified a version of Module::Build::Base from Module-Build-0.2611
to add YAML support sufficient to do everything that Module::Build needs.
In essence, I have replaced write_minimal_metadata() with write_metadata().
This new write_metadata() method does everything that is needed to
write META.yml
but it does it without YAML.pm. Thus, we could remove all dependency on YA=
ML.pm
completely. (Or, we merely use the internal routine if the external YAML.pm=
does
not exist.)
1. How exactly should I submit this? (I am not experienced with
submitting patches
in the "right form".) Should I check out from anonymous CVS? Do some =
diff
command? Can someone tell me the exact sequence of commands to get th=
e
right style of diff after I check out from CVS? Or do I just send
in my version
of Module::Build::Base?
2. I could also make the modification to the CVS HEAD. Do you want me
to do that?
3. Should we get rid of any dependence upon YAML.pm altogether?
We could use the internal routine exclusively. Or should we use
YAML.pm if it
exists and use the internal routine if it does not exist?
Please let me know.
Stephen
On 2/26/06, Ken Williams <ke...@ma...> wrote:
>
> 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-03-20 14:14:43
|
Stephen Adkins wrote: > I have modified a version of Module::Build::Base from Module-Build-0.2611 > to add YAML support sufficient to do everything that Module::Build needs. Excellent! > > In essence, I have replaced write_minimal_metadata() with write_metadata(). > This new write_metadata() method does everything that is needed to > write META.yml > but it does it without YAML.pm. Thus, we could remove all dependency on YAML.pm > completely. (Or, we merely use the internal routine if the external YAML.pm does > not exist.) I'm not Ken (nor do I play him on TV), but I'd actually suggest moving the code to a new module Module::Build::YAML, both for clarity (to separate the code for easier maintenance) as well as easier replacement (M::B can try to use YAML and only if it isn't found switch to using M::B::YAML instead). It may be that at some time in the future it would be useful to be able to /read/ YAML data (which requires the full YAML distro) instead of just /writing/ YAML (which the compatibility layer can handle nicely). > > 1. How exactly should I submit this? Check out a new working copy from CVS, then copy your changes in place and then run, e.g. $ cvs diff -u > yaml.diff If you do as I suggested above and separate the code into a new module, you will need to do a $ cvs add lib/Module/Build/YAML.pm before the above, so that you get the new file added too. HTH John -- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4501 Forbes Boulevard Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5748 |
|
From: Ken W. <ke...@ma...> - 2006-03-20 21:18:32
|
On Mar 20, 2006, at 8:14 AM, John Peacock wrote: > I'm not Ken (nor do I play him on TV), but I'd actually suggest > moving the code to a new module Module::Build::YAML, both for > clarity (to separate the code for easier maintenance) as well as > easier replacement (M::B can try to use YAML and only if it isn't > found switch to using M::B::YAML instead). An excellent idea, it will be nice to have it in its own .pm for ease of testing, better interface, etc. -Ken |
|
From: David G. <da...@hy...> - 2006-03-21 04:09:52
|
John Peacock wrote: > I'm not Ken (nor do I play him on TV), but I'd actually suggest moving > the code to a new module Module::Build::YAML, both for clarity (to > separate the code for easier maintenance) as well as easier replacement > (M::B can try to use YAML and only if it isn't found switch to using > M::B::YAML instead). It may be that at some time in the future it would > be useful to be able to /read/ YAML data (which requires the full YAML > distro) instead of just /writing/ YAML (which the compatibility layer > can handle nicely). Any chance this could be generalized further to handle all the YAML that CPAN.pm needs and free us from the tyranny of YAML prerequisites? Module::MetaYAML? Regards, David Golden |
|
From: Ken W. <ke...@ma...> - 2006-03-21 04:41:48
|
On Mar 20, 2006, at 10:09 PM, David Golden wrote: > John Peacock wrote: >> I'm not Ken (nor do I play him on TV), but I'd actually suggest >> moving the code to a new module Module::Build::YAML, both for >> clarity (to separate the code for easier maintenance) as well as >> easier replacement (M::B can try to use YAML and only if it isn't >> found switch to using M::B::YAML instead). It may be that at some >> time in the future it would be useful to be able to /read/ YAML >> data (which requires the full YAML distro) instead of just / >> writing/ YAML (which the compatibility layer can handle nicely). > > Any chance this could be generalized further to handle all the YAML > that CPAN.pm needs and free us from the tyranny of YAML prerequisites? > Possible, but I think we should get the first version of it with just the bare-bones writing capabilities. CPAN.pm also needs reading, and might therefore need the full capabilities of YAML.pm if someone puts whatever obscure YAML syntax into their YETI.mammal file. -Ken |
Thanks for helping keep SourceForge clean.
X