[Module::Build] Re: something broken between Module::Build, CPAN.pm, and ExtUtils::MakeMaker in 5.8.8 for UINST=1

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

John Peacock <jpe...@ro...> writes:
>Nick Ing-Simmons wrote:
>> Chromatic <chr...@wg...> writes:
>>> M::B provides the minimal features to get the module built, tested, and=
=20
>>> installed.  The bare tarball doesn't.  No slope.
>>=20
>> I would like to switch to module build but AFAIK it still can't=20
>> do nested builds.
>
>That discussion is happening on the Module-Build list even now.=20=20

Hmm, my subscription to that list seems to have gone AWOL.

>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

>
>Is this what EUMM does now?=20=20

Yes - with the possible exception of the depth-first, for some meaning of=
=20
depth-first. It works for both cases above ;-)

>This seems to be what GNU automake/autoconf=20
>seems to expect.
>
>John