Austin Schutz wrote:
To preface these comments, I'd like to say thanks for M::B existing in
the first place. It's really very handy, and I appreciate the pure-perl-ness
of it. I'm a bit of a newbie with it (and other makefile making utilities),
so I may have missed obvious things. However, I _tried_ to do a reasonable
job of checking the docs (and a bit of the list archives) before sending
this email.
My introduction to M::B this week was due to my packaging up of
a multi-language project I have, where I embedded Build(.PL) calls into
autoconf/automake files. Works very well, but here are several comments
regarding my experience with M::B:
Ok, here goes:
M::B makes use of 'backlink' in Pod::Html, a newer feature which
doesn't exist in the versions included with older perls. Possibly some other
conflicts, haven't gotten past this yet. IMO M::B should work with reasonably
old stable perls out of the box, because people are still developing for them
as targets.
Backwards compatability is one of Ken's goals. Most of the code is
compatable back to 5.005, I believe. However, it's possible that some
sneaked in. I think Randy Kobes contributed the htmldoc support; perhaps
he can help here if he's still on the list?
~/src/gxrancid> perl Build.PL --help
Deleting Build
Removed previous script 'Build'
Creating new 'Build' script for 'Rancid' version '1.1'
~/src/gxrancid>
Not too helpful. Build --help would be nice to support as well. It
could list all the possible targets and command line options, much as
configure --help does for autoconfed projects.
<quote>
The following build actions are provided by default.
help
This action will simply print out a message that is meant to help
you use the build process. It will show you a list of available build
actions too.
With an optional argument specifying an action name (e.g. Build
help test), the 'help' action will show you any POD documentation it can
find for that action.
</quote>
--install-base /path --install_path lib=/foo/lib didn't work for me.
one or the other gets overlooked. This is handy for compatibility with
automake, where all those variables are set automatically, and it would be
nice to be able to pass it on.
<http://tinyurl.com/48ex2>
<http://www.makemaker.org/wiki/index.cgi?ModuleBuildConversionGuide>
It's difficult to figure out from the docs how to replace the top
line of scripts with #!/...perl. Also difficult to figure out how to add
a 'use lib' line with the path so the accompanying perl libs will be found
and used.
Build install works great, Build uninstall not so great. :-)
Yeah, I hope this gets implemented soon. It's one of the big missing
targets IMO. I'd kinda like to see META.yml installed too, possibly as a
replacement for the old .lst files of MakeMaker.
It's not clear from the docs how to build non-perl targets. There
seems to be support for compiling/linking source files, but it's use is
not made clear from the docs. This may be more obvious to folks more
familiar with MakeMaker than I am. Really, it would be nice to be able to
have generic targets (which could be overridden for specific files) to be
able to build any associated file which is supposed to accompany the package.
The files I was working with on my project were C, perl, expect, and shell,
for example. My solution was to autoconf/automake the whole thing, but it
should be possible to do with M::B as well.
I thought this was documented, but I don't see it after a quick look.
Maybe there should be something in the Cookbook?
Are you having a specific problem or just generally looking for info on
building C libs? You might take a look in M::B's dist directory in
't/XSTest/Build.PL' <http://tinyurl.com/52pn5> for an example.
Module::Build->new( module_name => 'modname'): this confused me for
a while. What if I'm installing more than one module? Well, its obvious now
that by "module" it really means "set of modules and other stuff", but I
initially thought I had to create a new M::B object for every perl module I
was installing.
Yeah, this is something I hate. M::B deals with distributions not
modules. I think a better distinction could be made...
You might check the 'dist_name' parameter as an alternative.
M::B could support a different method of versioning. That's a
topic that would make this a really annoyingly long email, so I'm going
to follow this up in a different email.
What do you mean? Perhaps the 'versioninstall' target?
Randy.
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
| 
