[Module::Build] Re: Recursive Builds

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

Nick Ing-Simmons <ni...@in...> writes:
>>That discussion is happening on the Module-Build list even now.=20=20
>
>Hmm, my subscription to that list seems to have gone AWOL.

Now repaired but I can't think of a way to get this spliced into=20
existing thread.

So here is what I said on perl5-porters:

>
>>The=20
>>problem is that what "nested build" means is different for different=20
>>people.  Personally, I'd like blib/lib and blib/arch to contain all sub=
=20
>>blib's below the current one (strictly speaking a recursive build).  And=
=20
>>at any level, a './Build command' will run all lower level ./Build files=
=20
>>with the same command depth-first.
>
>That is roughly what my Tk and Audio::* want as well.
>The potential issue is when the depth-first part kicks in.
> - The Build.PL process needs to be top down so that toplevel Build.PL
>   can do the confugure-like tests needed by the children.=20
> - I have no trouble with actual build being depth first.
> - I need to control the order of child builds somehow, this could=20
>   be by tweaking the depth !
>
>e.g. for Tk:
> - Toplevel Build.PL figures out where Xlib lib and inc are.=20
> - One special child is pTk which is wrapper on core tk
> - other descendants are the major widgets.
>=20=20
>For Audio (::Data et. al)
> - Top level Build.PL decides which children _can_ be built
>   i.e. what audio hardware we have and which math and file format libs
>   are available.
> - Child builds are more-or-less independant
>

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=20
built and tested without siblings being built/present.

In this scheme a branch of tree can be lopped off or a new one=20
grafted on.=20