Re: [Module::Build] Recursive builds?

[alan <al...@pa...>]

On Fri, 10 Feb 2006, Ken Williams wrote:

> On Feb 10, 2006, at 10:47 AM, Peter Scott wrote:
>
> > Hi there.  This sounds like a FAQ, but I have searched high and low
> > and not found it answered anywhere.  Are there any examples around for
> > using M::B for recursive builds, where you have a directory tree and
> > each directory has its own Build.PL?  Seems like someone must have
> > done that already, but darned if I can find it.
>
> It also sounds not-too-difficult to me, but I don't actually know of
> anyone that's done it either.  Anyone?
>
>   -Ken

About 2 years ago, I submitted my ideas and possibly even patches,
related to this. My changes create a subclass of Module::Build to
support recursive builds, as well as other features which are either
less useful to the general public, or historically irrelevant
considering more recent versions of Module::Build.

After some discussion on-list, it was decided that most of my changes
were inappropriate for Module::Build's primary goal of being a build
tool for CPAN. Since then, I've seen the big problems Module::Build has
to solve without supporting non-CPAN functionality, I have come to agree
with this assessment.

Regarding the specific case of recursive builds: our changes are not
perfect, and probably don't support many features of Module::Build which
we don't happen to use. But we've been using them in production for a
large project (63 Build.PL's if you start the build from the root) and
have had no problems in actual practice, for what we do. (Note that
"./Build dist" is _not_ something we have ever done or ever intend to
do, and likely won't do anything useful.)


The primary problem with doing recursive builds correctly which I had to
solve (and which MakeMaker got wrong at the time), is the tradeoff
between "make test" and "make install" in a subtree of the project.

When you do a "make test" in a subtree of the build tree, you typically
want it to use a blib which contains the (most recently built) contents
of the _entire_ build tree (not just your subtree). If you don't, "make
test" in a subtree uses the installed versions of modules in other
subtrees of the build, instead of reading the blib versions. (The reason
is a problem for us is because we wanted to be able to test interactions
between modules in different branches of the build tree, without testing
Everything, during normal development cycles.)

On the other hand, when you "make install" in a subtree, it should
install only that subtree of code.

I solved these problems by copying the source files into 2 separate
blib's: one at the root of the tree holds "everything" and is used only
for "make test". A blib inside each separate build directory stores just
the files for that specific build, and is used to install subtrees
correctly at "make install" time.


In summary:

If you want a solution which might do what you want and expect, but
doesn't have full support for all features Module::Build uses, then I
can most likely provide this (I'll have to get permission again but I
expec this is a formality). I would hesitate to suggest it be merged
into Module::Build, however, because I agree that most of what I do is
inappropriate for use in distributed modules intended for use by someone
other than the module's developer.

Thanks,
Alan Ferrency
pair Networks, Inc.
al...@pa...