Re: [Module::Build] Recursive builds?

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

Before anyone starts designing recursive builds again, I recommend
hitting the module-build-general archive for February/March 2004, and
checking out the threads "Recursive Build Patch" and "Some thoughts on
recursion."

http://sourceforge.net/mailarchive/forum.php?forum=module-build-general

I'm not interested in going over any of my old points again, because I
fully admit that what I am doing is not within the main focus of
Module::Build. I don't expect my existing recursive build patches would
be useful in the design or implementation of an official Module::Build
recursive build system, even though they work fine for me now.

I only wanted to make it known that my solution exists, in case there is
anyone else who may benefit from it.

On Mon, 13 Feb 2006, Eric Wilhelm wrote:

> # from alan on Monday 13 February 2006 07:18 am:
>
> > 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).
>
> I'm curious as to how many users want this behavior. I'm thinking that
> anything done in a subtree should be no different than if I were
> building just that subtree.

I don't know, but I'd expect you're right: not many people would
need this.

As I said, my changes aren't available on CPAN, because they're
inappropriate for use in public distributions. But, we are willing to
share our solution if it would be useful (with the understanding that
you're best off not using it for publicly distributed modules).

> i.e.  "the recursive build system only recurses down and never up" seems
> like a good design theme.
>
> The behavior you describe doesn't fit the definition of "recursive."

My system does not "recurse up." Sub-builds simply have access to, and
modify, a global store of information. I don't know of any definition of
"recursive" which precludes this.

That said, I have no argument against the spirit of your design theme
w.r.t recursive builds in Module::Build, as long as I can get the job
done (and I can).

> > "make test" in a subtree uses the installed versions of modules
> ... [which is bad because we want] ...
> > to test interactions between modules
>
> I think this sort of testing should be enabled by running "./Build test
> Module-Name" from the toplevel.  This would then do something like:

This could solve my original problem, although in a less convenient way,
in practice.

>   1.  run "depends" actions (depth first) for all subdirs
>   2.  make a -Ipath/to/Module/blib/lib/ list including all subdirs
>   3.  run ACTION_test for the Module-Name dir

The biggest problem I'd have with this is that it seems like it would be
quite slow in my application, if testing one subtree had to traverse the
entire build tree before running a single test file.

Currently, I do:

1. one slow "./Build" at the root, which builds multiple blib/
   directories.
2. multiple "./Build test" in arbitrary subtrees are then fast: they
   do not have to traverse any portion of the build tree that isn't
   being tested, and @INC gains only one new directory (instead of the
   63 separate blib's I would have in your solution).
3. subsequently, a "./Build" in a subtree is adequate for all other
   modules to see any changes in that subtree.

> There's also something about dependencies in the Build.PL stage.  Maybe
> the toplevel Build.PL could gather all of the META.yml info and inform
> the workers about which dependencies are satisfied by their peers.

We don't currently use the Module::Build dependency specification for
"other modules within the same recursive build." Expect to deal with the
case where someone hands you multiple mutually dependant sub-builds,
even if you may not think this makes sense.

(Also, my build system has no official "top level Build.PL". There is no
extra configuration required in any Build.PL, and any subtree of the
build can act as "the top level Build.PL" if you let it. My build tree
is deep, not simply flat and wide.)


Thanks,

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