Re: [Module::Build] Re: Recursive Builds
Status: Beta
Brought to you by:
kwilliams
|
From: Nick Ing-S. <ni...@in...> - 2006-02-16 22:10:00
|
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 |