Can anyone add to this?
I posted this list of reasons why I don't use Module::Build, to the
Module::Build list, not to cheese anybody off, but mostly cause somebody
there asked me to.
Then somebody there said I should get off the pot and submit some code.
I'm considering that, but I thought I'd better find out the size of the
beast. So, can anybody add to this list?
* the xs tools are EU::MM centered. h2xs produces a Makefile.PL, not a
Build.PL. this is a big problem. h2xs would have to be re-written to
produce a Build.PL file.
* the xs tutorials are all EU::MM centered. perlxstut, etc. another
big problem.
* Module::Build only understands a very small set of targets, while
make's is comprehensive. This is an intractable structural problem,
cause make is at the center of all this, and Module::Build is perl
specific and really just a johny-come-lately. The best solution is to
have Module::Build call out to make for unknown targets.
* recursive builds. Module::Build's c_source option is not adequate. i
may want to build a library or an executable, not a bunch of object
files. secondly, i may not want to compile all the c files in the
directory. thirdly, the directory may have non-c files that are part of
the build. fourthly, the build may be conditional. for example,
bzlib-src in Compress::Bzip2, where i needed to conditionally build a
library, executables, and not compile the extensive test suite. why you
ask did i include files that weren't part of the standard build? it's
not my code. i didn't read the terms of use too closely, but to be safe
i put all the files in that fit.
* tweaking builds to add compiler flags and such. i don't know how to
do that with M::B. getting through the hoops on ms windows would have
been impossible without this.
* need to be able to add custom linker flags. linking in an external
library isn't always as easy as -Lxxx -lxxx, especially if it's a
dynamic lib. Often you have to add custom linker flags to bind the
dynamic lib location to the compiled perl module. Usually this is
necessary when the library is not in a standard location.
* recursive builds for perl modules (not c code as above). I've had
projects that i structured with nested packages mostly for development.
The nested packages were co-requisites that were intended to be
installed separately to a production environment. I had a number of
test environments, with all the packages being modified ongoing. EU::MM
very nicely allowed me to package them all in the same directory while
retaining their independent nature. when i ran the Makefile.PL in the
top directory, it descended into the other package directores i either
symlinked in or copied in, and installed them all into the same blib.
very handy. some of them were xs, datetime speedups, lru caches on perl
structures, alternate associative array structures that were faster than
perl's hashes, had a smaller footprint, and intrinsically sorted too.
having them in separate blibs would have been impossible to deal with.
recursive builds are not in M::B as far as I can tell.
* make -n equivalent. is there a way to do a dry run of the build with
M::B?
* constant definitions derived from parsing a .h file. It's hard to
stop EU::MM from doing this, but i don't know how to coerce M::B to even
start doing this. Moreover, EU::MM allows options for tweaking the
constant definitions.
* makefiles. make is the ant for c. importing a c project is easier if
you can deal with makefiles. M::B starts with the assumption that make
is not there. however, when M::B comes to deal with c code, that is
actually an unreasonable assumption. i can't think of any c development
environment that is missing make in some form or other.
--
Rob Janes
a r j a y a t c p a n . o r g
