Rob Janes <[EMAIL PROTECTED]> writes:
>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.
I don't see that as a big problem:
A. The Makefile.PL and Build.PL it builds are boring boiler-plate.
So it isn't a re-write but as small addition.
B. I don't use h2xs anyway ;-)
>
>* 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.
The number of targets you really need isn't that large.
But I agree you need a few
.xs -> .o
.c -> .o
.cpp -> .o
*.o -> .so / .dll
The snag is that these need to integrate with the architecture
of Module::Build (which needs co-operation from M::B folk).
>
>* recursive builds.
The complete lack of that is why I haven't ever got into M::B.
In principle it is a simple
do $_ foreach glob("*/Build.PL");
The snag (as EU::MM shows) is sharing namespace(s) and passing
config data down.
>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.
perl/Tk does the same (in spades!) - by including most of Tcl/Tk files
than then cherry-picking what gets built.
Likewise Audio::* includes drivers for various sound APIs
and conditionaly compiles.
>
>* 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?
A nice to have - one way might be to override system() or whatever
it uses to invoke tools.
>
>* constant definitions derived from parsing a .h file. It's hard to
>stop EU::MM from doing this,
It is h2xs that does that. Botched parse of .h is why I don't use it.
(Sadly my replacement code is just as fragile.)
>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.
The essence of this is the hook that can cause a .xs file to be
generated somehow. Does M::B allow Foo.xs.PL ?
>
>* 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.
I can see both sides here.
On the one hand if you know make exists then Build.PL can
always system("make") as last resort.
On the other part of motivation from M::B is that
BSDmake != gnumake != sunmake != nmake != dmake
In particular on Win32 the hoops you have to jump through to get
arglists into temp files are radically different.
