Re: [Module::Build] Re: Recursive Builds

[Nick Ing-S. <ni...@in...>]

Ken Williams <ke...@ma...> writes:
>On Feb 16, 2006, at 1:52 PM, Nick Ing-Simmons wrote:
>> So in both cases the descendants cannot run without the parent,
>> and need parent's blib etc. about to run their tests.
>> Parent has some tests of its own. Different children can be
>> built and tested without siblings being built/present.
>
>The main problem I see with this approach is what happens when you=20
>'install' from a child directory.=20=20

I agree that makes no sense in this scheme.=20
In the MakeMaker world there is nothing in child blib so=20
install in there has nothing to copy and is naturally a no-op.
I would be happy to put an explict install-does-nothing over-ride=20
in child Build.PL file(s).

>You've tested with other blibs=20
>active, but I'm hearing people say an 'install' here should only=20
>install the child stuff, so there's a good chance things will be broken=20
>after installing since it tested with different sibling code.
>
>I can think of a few solutions to this=20

Such as? (appologies if they have been discussed already...)

>but none so far that seem to=20
>satisfy all the use cases.

I suspect that there are "a few" typical cases e.g.:

A. A bundle of more or less unrelated modules put in a tree
   for convienience of building whole or sub-projects.

B. Toplevel + a "library" subdir that builds a .a file for=20
   toplevel. e.g. Compress::Zlib could have "the" open-source zlib=20
   distribution as a child dir with addition of a Build.PL to build=20
   libz.a if system didn't have -lz

C. Framework module (like Tk or DBI) with tightly coupled=20
   sub-dirs.

Tk itself has all those elements but is (I hope!) not typical.

So we need a "few" kinds of child Build.PL - an un-adorned one=20
could handle the "simpl" (A) case, with specialist cases being handled=20
by overrides of some kind.




>
>  -Ken