#115 Module::Build support

None
closed-out-of-date
Chris Dolan
None
5
2013-10-02
2004-07-27
Chris Dolan
No

The Perl Module::Build project is an attempt to remove
the dependence on make. Modules that support this
effort include a Build.PL file instead of or in
addition to a traditional Makefile.PL file. To build a
package this way, replace the usual:

perl Makefile.PL
make
make test
make install

with

perl Build.PL
./Build
./Build test
./Build install

The attached patch is an first-cut attempt to make fink
autodetect Build.PL files and use them if present
during the compile and installation phases.

Not many modules support Module::Build yet, but it is
expected to become the default in the future since it
removes much of the headache of supporting various
versions of make on all the platforms.

Alternatively, fink could support a new flag in the
.info files to force Build.PL support, but I think that
is overkill when autodetection is so simple.

Discussion

1 2 > >> (Page 1 of 2)
  • Chris Dolan
    Chris Dolan
    2004-07-27

    PkgVersion.pm patch to autodetect and support Buid.PL

     
    Attachments
  • Daniel Macks
    Daniel Macks
    2004-08-02

    Logged In: YES
    user_id=535292

    Which PkgVersion.pm is this .patch for?

    OTOH, having a *Script default that changes based on
    contents of a package's tarball makes debugging the package
    difficult. For example, it means one could not query the
    package "what script will be used?" without actually
    downloading and unpacking the source. Thus far, we have not
    taken that step for any of the fields. Would there be a way
    to re-implement this with a constant script, where this
    script (not its creator) makes the decision about
    Makefile.PL vs. Build.PL using shell logic?

     
  • Chris Dolan
    Chris Dolan
    2004-08-02

     
    Attachments
  • Chris Dolan
    Chris Dolan
    2004-08-02

    Logged In: YES
    user_id=50365

    Here's a version of the patch that implements the Build.PL
    vs. Makefile.PL decision in shell script. I'm usually a csh
    user instead of bash, so I apologize if there's an error in
    the sh scripting.

    I haven't yet tested this patch, as it's still in the
    brainstorming stages.

    The patch is against PkgVersion.pm v1.00 from fink v0.20.5,
    distribution v0.7.0.cvs. Sorry, I had meant to include
    those numbers in my first submission...

     
  • Daniel Macks
    Daniel Macks
    2004-08-11

    Logged In: YES
    user_id=535292

    *Script fields are executed one line at a time, so a
    multi-line if/then/else construct won't work.

     
  • Chris Dolan
    Chris Dolan
    2004-08-11

    Update for v0.21.1 and one-line ifs

     
    Attachments
  • Chris Dolan
    Chris Dolan
    2004-08-11

    Logged In: YES
    user_id=50365

    OK, I made the if/else/fi into single line commands
    (although they are broken into multiple lines in the Perl
    code for readability. I also updated the patch for Fink v0.21.1

     
  • Logged In: YES
    user_id=12221

    Module::Build and MakeMaker use different install flags. So
    simply switching out "make install" for "./Build install"
    isn't going to work. I believe this will do it (untested):

    ./Build install --install_base=%i --install_path
    lib=%i/lib/perl5$perldirectory --install_path
    arch=%i/lib/perl5$perldirectory/$perlarchdir --install_path
    libdoc=%i/share/man/man3 --install_path
    bindoc=%i/share/man/man1 --install_path script=%i/bin
    --install_path bin=%i/bin

     
  • Daniel Macks
    Daniel Macks
    2004-09-21

    Logged In: YES
    user_id=535292

    I wonder if using a new Type:PerlBuild might be a better way
    to handle this type of package? It seems like that would
    make it easier to patch into fink, and would make
    $Maintainer feel more in control of the process.

     
  • Chris Dolan
    Chris Dolan
    2004-09-23

    Logged In: YES
    user_id=50365

    Daniel's Type:PerlBuild is reasonable, but I believe that it
    is overkill. I prefer autodetection of Build.PL files. The
    Module::Build folks have made it their goal to for Build.PL
    to replace Makefile.PL as the standard in the future (a
    notion that I support), so I think an autodetect is more
    future-looking.

    Attached is another version (v4) of the patch with Michael
    Schwern's correction applied. Please note that this patch
    is still wholly untested. My next step, time permitting,
    will be to find/build a .info file for a module with a
    Build.PL and test out the patch.

     
  • Chris Dolan
    Chris Dolan
    2004-09-23

    Updated patch to use correct Build install arguments

     
    Attachments
  • Daniel Macks
    Daniel Macks
    2004-10-05

    Logged In: YES
    user_id=535292

    Our %c default for Type:perl is full of INSTALLPRIVLIB and
    other things that schwern says are MakeMaker specific. Do we
    therefore need to change %c for Build.PL?

     
  • Chris Dolan
    Chris Dolan
    2005-02-13

    Logged In: YES
    user_id=50365

    I've finally made progress on this item. I've reassigned
    the bug to myself, and I've written a new patch from
    scratch. Feedback is GREATLY appreciated. Should I go to
    the devel maillist with this?

    The new patch does the following:
    When creating the default %c, CompileScript or
    InstallScript, fink checks the BuildDepends to see if
    module-build-pm is present in the list. If so, it changes
    the normal Makefile.PL stuff to the Module::Build
    equivalent, using Build.PL and appropriate arguments. I
    cribbed off Blair Zajac's CompileScript for
    module-build-pm.info to get the arguments. But I made the
    very important improvement of specifying paths agains %p
    during the compile phase and against %i during the install
    phase. Blair's module uses just %i, which is fine for
    pure-perl libs but wrong for XS-based modules, I think.

    Questions:
    * What do you think of the way I checked for Module::Build
    in the BuildDepends? Good/bad??
    * Where should this behavior be documented? On the
    Packaging Reference web page at minimum, I would think.

     
  • Chris Dolan
    Chris Dolan
    2005-02-13

    • assigned_to: nobody --> chrisdolan
     
  • Chris Dolan
    Chris Dolan
    2005-02-13

    Completely rewritten patch that looks at BuildDepends

     
    Attachments
  • Logged In: YES
    user_id=12221

    * What do you think of the way I checked for Module::Build
    in the BuildDepends? Good/bad??

    Why not just do what the CPAN shells do and look for the
    existence of a Build.PL file in the top level directory?

     
  • Chris Dolan
    Chris Dolan
    2005-02-14

    Logged In: YES
    user_id=50365

    Michael Schwern wrote:
    > Why not just do what the CPAN shells do and look for the
    > existence of a Build.PL file in the top level directory?

    Three reasons:
    * Some naughty CPAN modules have Build.PL files that
    aren't Module::Build specific. For example, Adam Kennedy's
    Class::Autouse has a Build.PL that says 'require
    "Makefile.PL";' and the Makefile.PL is based on Module::Install.
    * I think it's against the spirit of Fink to make
    decisions based on package content. I think the .info file
    should direct all of the decisions.
    * My solution keeps maintainers honest by forcing them to
    put module-build-pm on the BuildDepends line.

     
  • Blair Zajac
    Blair Zajac
    2005-02-14

    Logged In: YES
    user_id=9001

    I think having searching in the BuildDepends for the
    module-build-pm package seems a little like a one-off
    patch. This seems like something that would require
    special additional knowledge on how to build a Perl package.
    I would prefer to see a Type:PerlBuild type solution,
    although I recommend a different name, such as
    Type: Perl-Module-Build, as PerlBuild implies built by Perl or
    something, doesn't speak "Module::Build" to me.

    Regarding the %i and %p for modules that compile code, you
    could be correct, althought I haven't looked into it.

     
  • Daniel Macks
    Daniel Macks
    2005-02-14

    Logged In: YES
    user_id=535292

    I agree with chrisdolan, as I stated in my original comment
    on this item, that basing default *Script on source tarball
    contents is uncharted waters that I'd rather not see
    charted:) Checking BuildDepends seems like a more reasonable
    solution.

    Looking at modbuild.patch (#119815), seems like you're going
    to a lot of trouble to do the checking...do you really need
    to fire up the whole resolver just to do a regexp match on
    a $self->param_default()? The current implementation
    converts the given list of pkg names into PkgVersion objects
    and then all you do is convert them back to pkg names. Also,
    if BuildDepends has alternatives (cluster of pkgs joined by
    "|"), fink might prompt for help even if fink is only
    running in dumpinfo mode (i.e., no plan to actually use any
    of the cluster at all).

    Conversly, note thate resolve_depends, even when $_[0]==2,
    does more than just check BuildDepends (and may do even more
    in the future when we get fields like
    BuildDependsInherited). Especially for the feature at hand,
    better to make the fink policy simple ("must BuildDepends on
    module-build-pm*") so it's easy for maintainers to obey and
    us to enforce, and as side benefit simplifies implementation.

     
  • Chris Dolan
    Chris Dolan
    2005-02-16

    Logged In: YES
    user_id=50365

    I'm glad you said that, Dan. I had written it the way I did
    more out of fear of missing a detail than anything else. I
    ripped out most of the excess and am uploading a new version
    of the patch (modbuild.patch2).

     
  • Chris Dolan
    Chris Dolan
    2005-02-16

    removed depends_on function

     
    Attachments
  • Chris Dolan
    Chris Dolan
    2005-03-26

    Update patch to latest CVS Fink

     
    Attachments
  • Chris Dolan
    Chris Dolan
    2005-03-26

    Logged In: YES
    user_id=50365

    I updated the patch for the latest CVS Fink -- no changes on
    my part, just updated line numbers in the patch.

    I'd like this patch to go into Fink soon, but I don't want
    to commit it without positive feedback. Anything I can do
    to make it acceptable?

    To summarize: the patch changes the default CompileScript
    and InstallScript to use Build.PL instead of Makefile.PL if
    the .info package has Type: perl and the BuildDepends line
    includes module-build-pm. To make the choice between the
    normal Makefile.PL Compile/InstallScripts, the patch adds
    one simple function called "requires_module_build_pm" that
    returns a boolean.

     
  • Daniel Macks
    Daniel Macks
    2005-04-11

    Logged In: YES
    user_id=535292

    Seems like a fine approach to me. You could probably
    optimize requires_module_build_pm to use $_ instead of
    continually recreating the $dep lexical var? Or maybe scrap
    the loop altogether and use a single regex something like:
    $self->pkglist_default("builddepends","") =~
    /(\A|,)\s*module-build-pm/

     
  • Chris Dolan
    Chris Dolan
    2005-04-13

    Simplify requires_module_build_pm() and update patch to latest CVS Fink

     
    Attachments
1 2 > >> (Page 1 of 2)