lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marvin Humphrey <>
Subject Re: [lucy-dev] Build support classes for C extensions
Date Thu, 05 Apr 2012 05:22:58 GMT
On Wed, Apr 4, 2012 at 12:20 PM, Nick Wellnhofer <> wrote:
> I posted some initial patches to LUCY-215 (patches 0004 - 0013):
> I took a simpler approach by using a hashref as config object. Module::Build
> generates very nice accessors for them.

The patch sequence looks great.  +1 to commit, with the caveat that I'd like to
relitigate the minimum version for Module::Build. :)

A few notes:

  * There are several nice implementation improvements and simplifications!  I
    particularly enjoyed this one:

  * The end product, Clownfish::CFC::Perl::Build has no POD describing its
    public API.  That's the most important part!  You're such a strong coder
    that we can have a lot of confidence in your implementations -- but we
    need to build consensus about the public interface.

    I suppose all the features utilized by the extension Build.PL file you
    provided that are not in the Module::Build API constitute the
public API, no?

  * We currently require Module::Build version 0.2808_01, which is what
    shipped with Perl 5.10.0.  I'm reluctant to bump the Module::Build version
    number to 0.3404 in order to get c_source accepting multiple directories,
    since that would exclude stock installs of Perl 5.10.x and 5.12.x.  Can we
    remain with 0.2808_01 and hack up something approximating the
    clownfish_params property instead of bumping to 0.31 to get

  * See for why we have been
    avoiding M::B#dist_version up till now.  Man, how I hate Perl's TMTOWTDI
    version numbers.  :(

    I'm OK with this change nevertheless, because the worst it will do is
    cause XSLoader to error out because of a mismatch between an X.Y.Z version
    in the shared object and an X.YYYZZZ version in  If that happens,
    we'll get a bunch of CPAN testers failures.

  * I'd like to do some work on parcels.  It looked like you were handling
    them as an implementation detail to be generalized, so I don't think we'll

  * It would be nice to get some of the configuration stuff out of this module
    and into Charmonizer, e.g. checking for compiler and compiler version and
    deriving compiler flags.  The flag deriving code has been duplicated in
    ruby/Rakefile, and we're going to start paying the price for violating
    DRY.  It would be nice to continue the work that Joe started last year
    consolidating our build systems; I have some ideas about how to go about

Marvin Humphrey

View raw message