FAQ
Eric Wilhelm pointed out that the new Makefile.PL doesn't work if
ExtUtils::CBuild isn't installed, so I released version-0.651 to fix that. Then
he pointed out that the overloaded numification of version objects didn't work
in the vpp.pm (pure Perl) mode. I pointed out that it didn't work at all, and
in fact isn't supported (since version objects are not intended to be used for
math operations). Consequently, he pointed out that Module::Build's
t/moduleinfo.t will fail, so I propose the following patch:

=== t/moduleinfo.t
==================================================================
--- t/moduleinfo.t (revision 1924)
+++ t/moduleinfo.t (local)
@@ -187,7 +187,8 @@
local $SIG{__WARN__} = sub { $warnings .= $_ for @_ };
my $pm_info = Module::Build::ModuleInfo->new_from_file( $file );

- cmp_ok( $pm_info->version, '==', '1.23',
+ # Test::Builder will prematurely numify objects, so use this form
+ ok( $pm_info->version == '1.23',
"correct module version ($i of $n)" );
is( $warnings, '', 'no warnings from parsing' );
$i++;

John

--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Blvd
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747

Search Discussions

  • Ken Williams at Jul 21, 2006 at 3:34 am
    Thanks, applied.

    -Ken
    On Jul 17, 2006, at 7:16 PM, John Peacock wrote:

    Eric Wilhelm pointed out that the new Makefile.PL doesn't work if
    ExtUtils::CBuild isn't installed, so I released version-0.651 to
    fix that. Then
    he pointed out that the overloaded numification of version objects
    didn't work
    in the vpp.pm (pure Perl) mode. I pointed out that it didn't work
    at all, and
    in fact isn't supported (since version objects are not intended to
    be used for
    math operations). Consequently, he pointed out that Module::Build's
    t/moduleinfo.t will fail, so I propose the following patch:

    === t/moduleinfo.t
    ==================================================================
    --- t/moduleinfo.t (revision 1924)
    +++ t/moduleinfo.t (local)
    @@ -187,7 +187,8 @@
    local $SIG{__WARN__} = sub { $warnings .= $_ for @_ };
    my $pm_info = Module::Build::ModuleInfo->new_from_file( $file );

    - cmp_ok( $pm_info->version, '==', '1.23',
    + # Test::Builder will prematurely numify objects, so use this form
    + ok( $pm_info->version == '1.23',
    "correct module version ($i of $n)" );
    is( $warnings, '', 'no warnings from parsing' );
    $i++;
  • Johan Vromans at Jul 22, 2006 at 9:26 am

    John Peacock writes:

    Eric Wilhelm pointed out [...], so I released version-0.651 to fix
    that. Then he pointed out [...] I pointed out [...] Consequently, he
    pointed out [...], so I propose the following patch:
    I know I'm not entitled to say this, and it will make me even more
    unpopular than I already am, but nevertheless I'm not going to remain
    silent.

    I don't know all the inner details, but this M::B and version dancing
    gives me the strong impression that something is terribly wrong here
    at a fundamental design level.

    Dealing with version numbers is not quite trivial, but should be
    fairly straightforward to deal with. I cannot (and for the time being
    I refuse to) believe that it takes 651 releases (652 at the time I
    write this) to get it right.

    I see that version.pm implements two flavours, a native perl version
    and XS. Under the assumption that both versions are functionally
    equal, I suggest to move the XS implementation to a separate module
    and have version.pm be a single, straightforward perl module that is
    easy to build, maintain, and to copy and paste into a distribution if
    necessary. I cannot imagine that the gain in efficiency is noticable
    for anything but an application that processes thousands of version
    numbers, and in that case the authors will know that, and they can use
    the XS version instead. It is better to have a good version.pm and a
    faster XS version, than a complex mix that may lead to future modules
    like version::lite, version::easy, or version::simple. Anyone
    notice a parallel with Ken's Module::Build::YAML?

    Please don't take me negative, it's just that my gut feeling is
    telling me that we all can save a lot of energy by chosing a
    different track.

    I no way I underestimate nor underappreciate the enormous amount of
    good work that you all do.

    -- Johan
  • Ron Savage at Jul 22, 2006 at 10:44 am
    On Sat, 22 Jul 2006 11:26:29 +0200, Johan Vromans wrote:

    Hi Johan
    I know I'm not entitled to say this, and it will make me even more
    unpopular than I already am, but nevertheless I'm not going to
    remain silent.
    I fully support your speaking up.
    I don't know all the inner details, but this M::B and version
    dancing gives me the strong impression that something is terribly
    wrong here at a fundamental design level.
    Clearly something's wrong, but it may not be anything big, even though it's a
    sort of show-stopper.
    Dealing with version numbers is not quite trivial, but should be
    fairly straightforward to deal with. I cannot (and for the time
    being I refuse to) believe that it takes 651 releases (652 at the
    time I write this) to get it right. Right!
    I see that version.pm implements two flavours, a native perl
    version and XS. Under the assumption that both versions are
    functionally equal, I suggest to move the XS implementation to a
    separate module and have version.pm be a single, straightforward
    perl module that is easy to build, maintain, and to copy and paste
    into a distribution if necessary. I cannot imagine that the gain in
    Exactly. Ship a pure-Perl version immediately and stuff around with an XS
    version off-line, so to speak. Pleeeeeeeeeeeeeeeeeeeaaaaaaaaaaassse!
    efficiency is noticable for anything but an application that
    processes thousands of version numbers, and in that case the
    Right!

    Everybody take a deep breath, and go back to basics!
    --
    Cheers
    Ron Savage, ron@savage.net.au on 22/07/2006
    http://savage.net.au/index.html
    Let the record show: Microsoft is not an Australian company
  • John Peacock at Jul 22, 2006 at 12:59 pm

    Ron Savage wrote:
    I don't know all the inner details, but this M::B and version
    dancing gives me the strong impression that something is terribly
    wrong here at a fundamental design level.
    Clearly something's wrong, but it may not be anything big, even though it's a
    sort of show-stopper.
    The problem is one of communication and insufficient testing, not architectural.
    I didn't think to test on a machine that didn't have *either* M::B or
    version.pm installed (which is the only case where there is any problem).
    Additionally, I was busy with real life and I didn't notice that Ken released a
    non-alpha release on a Friday (not placing blame, just noting the facts).
    Dealing with version numbers is not quite trivial, but should be
    fairly straightforward to deal with. I cannot (and for the time
    being I refuse to) believe that it takes 651 releases (652 at the
    time I write this) to get it right.
    It hasn't taken that many releases; I'm using the additional digit to
    distinguish that the last three releases have included no code change, only
    Makefile.PL tweaking.
    Exactly. Ship a pure-Perl version immediately and stuff around with an XS
    version off-line, so to speak. Pleeeeeeeeeeeeeeeeeeeaaaaaaaaaaassse!
    What you are both unaware of is that the XS code is the reference
    implementation, and is exactly the same code as appears in Perl v5.10.0 and has
    been basically stable for 8 months (some minor edge cases notwithstanding).
    The pure Perl implementation is newer, but no less stable.

    The problem is one of integration. I started using Module::Build for version.pm
    itself more than a year ago, because it made handling both XS and Perl code much
    more naturally. It didn't occur to me that on a virgin machine, version depends
    on M::B which depends on version, hence a problem.

    I gave Ken the choice of embedding a cut-down version.pm in the Module::Build
    stack, and rightly so, he declined because of the coordination issue (whether it
    was put into /inc or /lib) of having someone else's code, with a different
    release cycle, inside his distribution. He may reevaluate that now; I am fully
    prepared to maintain a parallel code inside M::B (since the code is already
    modular enough to support that).

    John

    --
    John Peacock
    Director of Information Research and Technology
    Rowman & Littlefield Publishing Group
    4501 Forbes Blvd
    Suite H
    Lanham, MD 20706
    301-459-3366 x.5010
    fax 301-429-5747
  • Eric Wilhelm at Jul 22, 2006 at 4:12 pm
    # from John Peacock
    # on Saturday 22 July 2006 05:59 am:
    The problem is one of communication and insufficient testing
    Hmm. Is there some way that we could test new releases in several
    combinations of platform/perl-version/installed-modules environments?

    Seems like somebody should build one of those :-)
    he declined because of the coordination issue (whether it
    was put into /inc or /lib)
    A couple of things from my experiment. I'm open to suggestions on the
    names (and whether dep is needed at all is a matter of whether you want
    to assert that we always use the bundled version.pm to bootstrap
    (regardless of whether one is installed.))

    This could essentially go in inc/. It is only for bootstrapping.
    dep
    -- version
    `-- vpp.pm
    `-- version.pm

    And after we've loaded our bootstrapping code, we keep it in @INC while
    we build our required dependencies. Then we stick them in @INC while
    we test. (And of course we still need to install them -- I haven't
    done that bit.)

    These are just drops of the unpacked tarballs straight off of CPAN.

    dependencies/
    -- ExtUtils-CBuilder-0.18
    -- Build.PL ...
    -- lib
    ...
    `-- version
    -- Build.PL ...
    -- lib
    ...

    I was toying with naming those. I think it's best to leave the "-*"
    version number on the directory and discover it (or have whatever
    fetches them write it somewhere.)
    of having someone else's code, with a
    different release cycle, inside his distribution.
    In the general case, all of the optional and required dependencies just
    go in "dependencies/" -- roughly: "curl $cpan_filename | tar -xz".
    The only place this gets tricky is when you want to bundle something
    that was just released and hasn't gotten to your mirror, but otherwise
    it should be as simple as:

    ./Build update_bundles
    I am fully prepared to maintain a parallel code inside M::B
    (since the code is already modular enough to support that).
    Wouldn't it be easier to write Ken a script that copies those two files
    out of (glob("dependencies/version*"))[-1] into dep/ or inc/?

    --Eric
    --
    "Everything should be made as simple as possible, but no simpler."
    --Albert Einstein
    ---------------------------------------------------
    http://scratchcomputing.com
    ---------------------------------------------------
  • Ken Williams at Jul 25, 2006 at 4:07 pm

    On Jul 22, 2006, at 11:11 AM, Eric Wilhelm wrote:

    # from John Peacock
    # on Saturday 22 July 2006 05:59 am:
    The problem is one of communication and insufficient testing
    Hmm. Is there some way that we could test new releases in several
    combinations of platform/perl-version/installed-modules environments?
    I would LOVE that.

    -Ken
  • David Golden at Jul 25, 2006 at 6:05 pm

    Ken Williams wrote:
    Hmm. Is there some way that we could test new releases in several
    combinations of platform/perl-version/installed-modules environments?
    I would LOVE that.
    http://ali.as/pita/

    I think some progress was made at the YAPC hackathon. Adam would have
    to give a more complete update.

    David
  • Eric Wilhelm at Jul 26, 2006 at 7:09 am
    # from David Golden
    # on Tuesday 25 July 2006 11:04 am:
    http://ali.as/pita/

    I think some progress was made at the YAPC hackathon.  Adam would have
    to give a more complete update.
    new site http://pitatesting.org/

    --
    [...proprietary software is better than gpl because...] "There is value
    in having somebody you can write checks to, and they fix bugs."
    --Mike McNamara (president of a commercial software company)
    ---------------------------------------------------
    http://scratchcomputing.com
    ---------------------------------------------------
  • Ron Savage at Jul 23, 2006 at 12:07 am
    On Sat, 22 Jul 2006 08:59:13 -0400, John Peacock wrote:

    Hi John
    The problem is one of communication and insufficient testing, not
    architectural. I didn't think to test on a machine that didn't have
    *either* M::B or version.pm installed (which is the only case where
    there is any problem). Additionally, I was busy with real life and
    OK. Many thanx for the clarification.

    I started a new job last Monday, and none of the machines have either version or
    M::B, so I was holding off installation, being distressed by the confusion, and
    not wanting to land in hot water.
    What you are both unaware of is that the XS code is the reference
    implementation, and is exactly the same code as appears in Perl
    v5.10.0 and has been basically stable for 8 months (some minor
    edge cases notwithstanding). The pure Perl implementation is newer,
    but no less stable. OK.
    distribution. He may reevaluate that now; I am fully prepared to
    maintain a parallel code inside M::B (since the code is already
    modular enough to support that).
    OK. So what steps do you suggest I take, exactly (in my situation only)?

    --
    Cheers
    Ron Savage, ron@savage.net.au on 23/07/2006
    http://savage.net.au/index.html
    Let the record show: Microsoft is not an Australian company
  • Johan Vromans at Jul 23, 2006 at 1:02 pm

    John Peacock writes:

    The pure Perl implementation is newer, but no less stable.
    So what is the reason to continue the XS version, except maybe as a
    separate module for the few cases that require speed?

    A clarification: when distributing (real) Perl applications to (real)
    customers, these are distributed in directly installable form.
    Customers install, they do not build, and they shouldn't need to.

    Having to deal with additional (CPAN) modules is a complication, but
    doable if plain Perl, since they play nicely with a vast range of Perl
    versions. Having to deal with XS modules is often a show stopper,
    since this would require separate distributions for different Perl
    versions and platforms.

    -- Johan
  • Chris Dolan at Jul 23, 2006 at 1:10 pm

    On Jul 23, 2006, at 8:01 AM, Johan Vromans wrote:

    John Peacock <jpeacock@rowman.com> writes:
    The pure Perl implementation is newer, but no less stable.
    So what is the reason to continue the XS version, except maybe as a
    separate module for the few cases that require speed?
    As John said yesterday, the XS version is the reference
    implementation and the PP version is a port. The XS version is
    already in core for bleadperl, so the PP version exists only for
    backward compatibility for people who can't or won't install the XS
    version.

    Chris

    --
    Chris Dolan, Software Developer, Clotho Advanced Media Inc.
    608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
    vCard: http://www.chrisdolan.net/ChrisDolan.vcf

    Clotho Advanced Media, Inc. - Creators of MediaLandscape Software
    (http://www.media-landscape.com/) and partners in the revolutionary
    Croquet project (http://www.opencroquet.org/)
  • Johan Vromans at Jul 23, 2006 at 2:22 pm

    Chris Dolan writes:

    As John said yesterday, the XS version is the reference
    implementation and the PP version is a port.
    He also said that it is 'as stable', so it is as good as the XS
    implementation.
    The XS version is already in core for bleadperl, so the PP version
    exists only for backward compatibility for people who can't or won't
    install the XS version.
    Which leads to the obvious choice to provide a PP version.pm for
    backward compatibility, and use the XS version in blead.

    As I tried to explain, non-core XS modules are often a pain and we
    should try to avoid them unless really needed (for speed, or for
    functionality). If a good PP alternative exist, let's use it.

    -- Johan
  • Ken Williams at Jul 24, 2006 at 6:11 am

    On Jul 23, 2006, at 8:10 AM, Chris Dolan wrote:
    On Jul 23, 2006, at 8:01 AM, Johan Vromans wrote:

    John Peacock <jpeacock@rowman.com> writes:
    The pure Perl implementation is newer, but no less stable.
    So what is the reason to continue the XS version, except maybe as a
    separate module for the few cases that require speed?
    As John said yesterday, the XS version is the reference
    implementation and the PP version is a port.
    I don't really get that - what does "reference implementation" give
    us? Does it just mean that if there's a bug in it, we can't fix it?
    Or that there's not a complete set of documentation describing its
    behavior?

    The wikipedia entry doesn't really seem to apply here, in any case:

    http://en.wikipedia.org/wiki/Reference_implementation

    -Ken
  • Johan Vromans at Jul 24, 2006 at 9:15 am

    Ken Williams writes:

    I don't really get that - what does "reference implementation" give
    us? Does it just mean that if there's a bug in it, we can't fix it?
    No, it means that this bug has to be implemented in all conformant
    implementations as well.
    Or that there's not a complete set of documentation describing its
    behavior?
    If there is, I haven't been able to locate it. It would really be
    helpful if there was a concise but complete document describing the
    intended behaviour of version objects -- in perl 5.10 as well as in
    compatibility mode.

    The reference implementation is supposed to implement these
    specifications, and prove that they are feasible. Unfortunately, in
    many cases, "reference implementation" is just another word for
    "standard by proof-of-concept".

    -- Johan
  • John Peacock at Jul 24, 2006 at 1:44 pm

    Ken Williams wrote:
    I don't really get that - what does "reference implementation" give us?
    Does it just mean that if there's a bug in it, we can't fix it? Or that
    there's not a complete set of documentation describing its behavior?
    I'm using "reference implementation" in the same sense that Sun's Java
    is the "reference implementation", as in it defined the public interface
    and the "default" implementation. The file vutil/vutil.c is *exactly*
    the same code as exists in the bleadperl/v5.10.0 util.c; indeed, when I
    fix something in vutil.c, I literally chop out the associated block in
    bleadperl/util.c and replace it with my code before generating the diff.
    This is not as easy as it sounds and some intervention was required to
    get ppport.h to support the same construct over all Perl releases from
    5.005_04 to the latest 5.8.x.

    The XS code in vutil/vxs.xs is more like the moral equivalent of the
    parallel code in universal.c (I can't cut/paste because h2xs does not
    produce comparable code with what exists in the core). Thankfully, the
    Perl-level interface (i.e. what the XS code implements) has changed very
    little over the last two years.

    Now, for the purpose of providing version.pm everywhere, I ported the
    XS/C code to pure Perl, and provided both in the same package with what
    I thought was the best tool to do so in a painless way: Module::Build.
    Unfortunately, when M::B became dependent on version.pm, all hell broke
    loose.

    I would prefer that the XS/C code be installed, by default, everywhere
    possible. It's always going to be faster and it has been around longer,
    so it is better tested. The pure Perl variant is a port, so it is
    inherently "second generation" code. There has already been an instance
    where a distro stupidly forced the pure Perl release, even though the XS
    was able to be compiled, in the misguided belief that the pure Perl
    release would be more portable. There are things that I do in the pure
    Perl release that are much less efficient than the XS/C release.

    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
  • Johan Vromans at Jul 24, 2006 at 8:05 pm

    John Peacock writes:

    The file vutil/vutil.c is *exactly* the same code as exists in the
    bleadperl/v5.10.0 util.c; indeed, when I fix something in vutil.c, I
    literally chop out the associated block in bleadperl/util.c and
    replace it with my code before generating the diff.
    Wouldn't it then be a better approach to have Perl expose the
    necessary entry point(s) so you can use them from XS, instead of
    having to go the way of cutting/pasting?

    -- Johan
  • Chris Dolan at Jul 24, 2006 at 8:14 pm

    On Jul 24, 2006, at 3:05 PM, Johan Vromans wrote:

    John Peacock <jpeacock@rowman.com> writes:
    The file vutil/vutil.c is *exactly* the same code as exists in the
    bleadperl/v5.10.0 util.c; indeed, when I fix something in vutil.c, I
    literally chop out the associated block in bleadperl/util.c and
    replace it with my code before generating the diff.
    Wouldn't it then be a better approach to have Perl expose the
    necessary entry point(s) so you can use them from XS, instead of
    having to go the way of cutting/pasting?
    This question makes no sense to me. If you are installing version.pm
    from CPAN today, then you must be using a Perl that doesn't have
    support for version.pm natively, so there's no entry point(s) to use.

    For Perl 5.9.x and (someday) 5.10+:
    version.pm XS is part of Perl itself
    (this is the definitive implementation of version.pm)
    version.pm PP is pointless

    For Perl 5.8.x and earlier
    version.pm XS == "cut-and-paste" code from Perl 5.9.x
    version.pm PP == port of the XS implementation to pure perl

    Chris

    --
    Chris Dolan, Software Developer, Clotho Advanced Media Inc.
    608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
    vCard: http://www.chrisdolan.net/ChrisDolan.vcf

    Clotho Advanced Media, Inc. - Creators of MediaLandscape Software
    (http://www.media-landscape.com/) and partners in the revolutionary
    Croquet project (http://www.opencroquet.org/)
  • Johan Vromans at Jul 24, 2006 at 9:57 pm

    Chris Dolan writes:

    Wouldn't it then be a better approach to have Perl expose the
    necessary entry point(s) so you can use them from XS, instead of
    having to go the way of cutting/pasting?
    This question makes no sense to me.
    Then I've probably misphrased my question.

    John points out that in blead, the C code of version is identical to
    but physically distinct from code in perl itself. It requires
    cut/paste to update one if the other changes.

    My suggestion is, that in that case, it would be better to have perl
    expose the necessary entry point(s) so version can call this entry
    point directly, instead of going the (tedious and error-prone) way of
    cut/paste.

    It's more a general suggestion, applyable to all cases where perl and
    corelibrary routines share code.

    -- Johan
  • John Peacock at Jul 25, 2006 at 1:05 am

    Johan Vromans wrote:
    My suggestion is, that in that case, it would be better to have perl
    expose the necessary entry point(s) so version can call this entry
    point directly, instead of going the (tedious and error-prone) way of
    cut/paste.
    Perl doesn't work like that (at least not until Perl6 at the earliest). The
    tokenizer is not pluggable (though some people have talked about making it so).
    The version code must be at the lowest level of the Perl source, because Perl
    itself uses it ($^V is now a version object). Also, the code in
    UNIVERSAL::VERSION is version-object aware (and is exactly the code that the
    CPAN release uses to support earlier Perl releases). I don't see of any way
    that it would be possible to make the version object code independent of Perl
    v5.10.0...

    John

    --
    John Peacock
    Director of Information Research and Technology
    Rowman & Littlefield Publishing Group
    4501 Forbes Blvd
    Suite H
    Lanham, MD 20706
    301-459-3366 x.5010
    fax 301-429-5747
  • Johan Vromans at Jul 25, 2006 at 9:11 am

    John Peacock writes:

    Perl doesn't work like that (at least not until Perl6 at the
    earliest).
    So this is the real fundamental problem. Oh well, we'll have to live
    with it for a while...

    -- Johan
  • David Golden at Jul 24, 2006 at 10:23 pm

    Chris Dolan wrote:
    For Perl 5.9.x and (someday) 5.10+:
    version.pm XS is part of Perl itself
    (this is the definitive implementation of version.pm)
    version.pm PP is pointless

    For Perl 5.8.x and earlier
    version.pm XS == "cut-and-paste" code from Perl 5.9.x
    version.pm PP == port of the XS implementation to pure perl
    So, for 5.9.x/5.10, is version supposed to be a dual-life module or is
    it compiled directly into the perl executable?

    Put differently, if 5.10.0 is released and a semantic bug is found in
    how version are handled, do we have to wait for 5.10.1 for a fix or can
    it be fixed immediately by installing version.pm X.YY?

    Regards,
    David Golden
  • John Peacock at Jul 24, 2006 at 9:49 pm

    Johan Vromans wrote:
    Wouldn't it then be a better approach to have Perl expose the
    necessary entry point(s) so you can use them from XS, instead of
    having to go the way of cutting/pasting?
    Don't ready too much into "cut/paste" in this context. My point was
    that the code that exists in vutil/vutil.c is exactly those lines from
    util.c in bleadperl that implement version objects. The XS code
    provides the Perl interface to those objects (oh, and initializes the
    overloading).

    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
  • Ken Williams at Jul 24, 2006 at 6:48 am

    On Jul 22, 2006, at 7:59 AM, John Peacock wrote:

    Ron Savage wrote:
    I don't know all the inner details, but this M::B and version
    dancing gives me the strong impression that something is terribly
    wrong here at a fundamental design level.
    Clearly something's wrong, but it may not be anything big, even
    though it's a
    sort of show-stopper.
    The problem is one of communication and insufficient testing, not
    architectural.
    I didn't think to test on a machine that didn't have *either* M::B or
    version.pm installed (which is the only case where there is any
    problem).
    Additionally, I was busy with real life and I didn't notice that
    Ken released a
    non-alpha release on a Friday (not placing blame, just noting the
    facts).
    I'll take the blame, but I won't feel very bad about it. =) I'm
    trying to be much more aggressive about releasing often than we did
    between 0.26xx and 0.28. That sucked. I don't mind releasing some
    stuff with bugs & dependency issues, or whatever, if the project
    keeps moving forward and the problems get fixed.

    -Ken
  • David Golden at Jul 22, 2006 at 1:00 pm

    Johan Vromans wrote:
    Dealing with version numbers is not quite trivial, but should be
    fairly straightforward to deal with. I cannot (and for the time being
    I refuse to) believe that it takes 651 releases (652 at the time I
    write this) to get it right.
    Nit - CPAN history has 0.50, 0.63, 0.64, 0.65, 0.651 and 0.652. Hardly
    652 releases.
    I don't know all the inner details, but this M::B and version dancing
    gives me the strong impression that something is terribly wrong here
    at a fundamental design level.
    I disagree. What you're seeing are the inevitable interactions of
    integrating two complex systems. Ideally, this would have been
    happening in some development branch behind the scenes. But since both
    are being tested in blead, you're seeing it live.

    The "dancing" is the result of one bad call, one complex problem and one
    big bug along the way:

    1) The Bad Call: version used Module::Build::Compat's "passthrough"
    mode, which is a bad idea in general and should never be used for any
    module that is or will become a Module::Build dependency.

    2) The Complex Problem: Dual XS/PP modules are not hard to do (e.g.
    Params::Validate), but they do require robust compiler detection across
    platforms, which is why version was trying to use M::B only. Borrowing
    custom Makefile.PL code from Params::Validate addressed that problem.
    (P::V's compiler detection code was recently tightened up for Win32
    thanks to Vanilla Perl)

    3) The Big Bug: M::B relied on YAML::Node to behave as a hash, when it's
    a tied hash that doesn't have real hash semantics. $node->{value} can
    be true but exists $node->{value} can be false. Who knew? The
    documentation for it is wrong. M::B was written to serialize version
    objects if a version object existed -- but the "exist" test failed.

    All three are specific, well-understood (in hindsight) and have now been
    addressed.

    None of it suggests a major design problem, with the exception that this
    does remind us of the relative fragility of the M::B bootstrap/upgrade
    process.

    The whole toolchain still depends on EU::MM being available to upgrade
    components that Module::Build depends on. Now I'll going into heretical
    territory myself and posit whether we should consider having M::B also
    rely on EU::MM for installation rather than having it try to bootstrap
    itself. I suspect that it would make upgrading M::B much easier and
    allow modules that depend on M::B to specify versions of M::B that they
    rely upon without self-upgrade problem that Adam Kennedy keeps pointing out.

    Essentially, everything would be EU::MM until M::B is installed.

    Food for thought.

    Regards,
    David Golden
  • Ron Savage at Jul 23, 2006 at 12:11 am
    On Sat, 22 Jul 2006 09:00:10 -0400, David Golden wrote:

    Hi David
    All three are specific, well-understood (in hindsight) and have now
    been addressed.
    We are probably all aware that many things, including hindsight, and clear in
    hindsight :-).

    --
    Cheers
    Ron Savage, ron@savage.net.au on 23/07/2006
    http://savage.net.au/index.html
    Let the record show: Microsoft is not an Australian company
  • Demerphq at Jul 23, 2006 at 1:11 pm

    On 7/22/06, David Golden wrote:
    2) The Complex Problem: Dual XS/PP modules are not hard to do (e.g.
    Params::Validate), but they do require robust compiler detection across
    platforms,
    Im a little confused about this one. I can think of a few modules that
    provide dual implementations that dont require robust compiler
    detection. Whats wrong with

    Are you set up to compile XS code [y/n]

    And then install the XS only if they answer yes? Is this a case of
    trying to come up with a high tech solution where a low tech solution
    would be just as good?

    Yves



    --
    perl -Mre=debug -e "/just|another|perl|hacker/"
  • David Golden at Jul 23, 2006 at 1:37 pm

    demerphq wrote:
    On 7/22/06, David Golden wrote:
    2) The Complex Problem: Dual XS/PP modules are not hard to do (e.g.
    Params::Validate), but they do require robust compiler detection across
    platforms,
    Im a little confused about this one. I can think of a few modules that
    provide dual implementations that dont require robust compiler
    detection. Whats wrong with

    Are you set up to compile XS code [y/n]

    And then install the XS only if they answer yes? Is this a case of
    trying to come up with a high tech solution where a low tech solution
    would be just as good?
    I would consider the use of prompt() with a sensible default to be a
    "robust" approach.

    :-)

    I suspect that ExtUtils::CBuilder::have_compiler() is likewise fairly
    robust. At least, I hope so, if M::B is going to be a replacement for
    needing make.

    Assuming things about qr/?make/ is not robust (example from DateTime-0.31):
    system( "$Config{make} test$Config{obj_ext}" )
    Which, for Vanilla Perl, gives:
    dmake: Error: -- Don't know how to make `test.o'
    The approach in Params::Validate (and borrowed for version.pm) uses
    ExtUtils::CBuilder, if installed, and otherwise tries manually against
    the configured CC, rather than make:
    system( "$Config{cc} -o test$Config{obj_ext} test.c" )
    Which, as a fall-back, is hopefully a bit more portable. Frankly, I'm
    not sure why it isn't just "$Config{cc} test.c", but I'm not very
    compiler savvy.

    These "high-tech" solutions seem fine to me if you want to default to
    the XS version (which most anyone with a compiler is likely to want).

    However, M::B *dependencies* have to use these techniques directly
    instead of relying on M::B to provide have_c_compiler() (which just
    wraps ExtUtils::CBuilder anyway).

    David
  • Nicholas Clark at Jul 24, 2006 at 3:56 pm

    On Sun, Jul 23, 2006 at 09:37:00AM -0400, David Golden wrote:

    The approach in Params::Validate (and borrowed for version.pm) uses
    ExtUtils::CBuilder, if installed, and otherwise tries manually against
    the configured CC, rather than make:
    system( "$Config{cc} -o test$Config{obj_ext} test.c" )
    Which, as a fall-back, is hopefully a bit more portable. Frankly, I'm
    not sure why it isn't just "$Config{cc} test.c", but I'm not very
    compiler savvy.
    The simplest reason that springs to mind is "what was the output file called,
    so that I can delete it?" I don't think that there's a standard across
    operating systems.

    Nicholas Clark
  • David Golden at Jul 24, 2006 at 4:50 pm

    Nicholas Clark wrote:
    On Sun, Jul 23, 2006 at 09:37:00AM -0400, David Golden wrote:
    system( "$Config{cc} -o test$Config{obj_ext} test.c" )
    Which, as a fall-back, is hopefully a bit more portable. Frankly, I'm
    not sure why it isn't just "$Config{cc} test.c", but I'm not very
    compiler savvy.
    The simplest reason that springs to mind is "what was the output file called,
    so that I can delete it?" I don't think that there's a standard across
    operating systems.
    I can see that. On the other hand, CPAN.pm doesn't "make clean" so the
    blib sticks around. One tiny object file wouldn't really bug me and it
    would be cleaned up when the cache is cleaned. But I guess it's better
    to clean up if one can. (Assuming -o is portable across most all
    compilers.)
  • John Peacock at Jul 24, 2006 at 9:48 pm

    David Golden wrote:
    I can see that. On the other hand, CPAN.pm doesn't "make clean" so the
    blib sticks around. One tiny object file wouldn't really bug me and it
    would be cleaned up when the cache is cleaned. But I guess it's better
    to clean up if one can. (Assuming -o is portable across most all
    compilers.)
    A) the test only sees whether you can compile a file (i.e. create an
    object file);

    B) EU::MM notices this object file and tries to link it in with the
    other object files (discovered in a sidebar with Eric Wilhelm);

    hence

    C) The Makefile.PL that now ships with version.pm deletes the test
    object file prior to writing the Makefile:

    map { unlink $_ if -f $_ } ('test.c','test.o');

    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
  • Nicholas Clark at Jul 24, 2006 at 9:50 pm

    On Mon, Jul 24, 2006 at 01:39:15PM -0400, John Peacock wrote:

    C) The Makefile.PL that now ships with version.pm deletes the test
    object file prior to writing the Makefile:

    map { unlink $_ if -f $_ } ('test.c','test.o');
    Surely that should be "test$Config{obj_ext}" else it's not going to work
    on VMS (and possibly elsewhere.

    Nicholas Clark
  • John Peacock at Jul 25, 2006 at 1:02 am

    Nicholas Clark wrote:
    map { unlink $_ if -f $_ } ('test.c','test.o');
    Surely that should be "test$Config{obj_ext}" else it's not going to work
    on VMS (and possibly elsewhere.
    Duh! I should be smarter than that (since we still have a VMS in production).
    I'll make that change momentarily...

    John

    --
    John Peacock
    Director of Information Research and Technology
    Rowman & Littlefield Publishing Group
    4501 Forbes Blvd
    Suite H
    Lanham, MD 20706
    301-459-3366 x.5010
    fax 301-429-5747

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupmodule-build @
categoriesperl
postedJul 18, '06 at 12:16a
activeJul 26, '06 at 7:09a
posts33
users9
websitecpan.org...

People

Translate

site design / logo © 2017 Grokbase