toplevel autoconfiscation design questions

toplevel autoconfiscation design questions

[Nathanael Nerode]

I've got fairly complete working autoconfiscations of the toplevel
directory going several times now.  Several important design choices
have come up:

* Should subdir/configure scripts be invoked from the top level
configure (where it is now), or from the top level Makefile?  (I've
worked out how to do both.)

Arguments for the configure script: no locking issues with the cache,
better documentation of options when & if we move to autoconf2.5x, what
else?

Arguments for the Makefile: configuration parallel with other processes,
don't configure subdirs you aren't using today, what else?

* Should the logic for ignoring missing subdirectories be in the
Makefile (where it is now), or in the configure script?

Arguments for configure: this is really a configure-time issue, it's
slower and uglier in the Makefile, what else?

Arguments for Makefile: it's there now, moving it may reveal subtle
issues, what else?

I'm still held up in actually doing this until my (or someone's) spu
autoconfiscation patch gets into gdb (since calling Cyngus configure
from a top level autoconf configure is... undesirable...).

But I might as well know which version of the autoconfiscation to work
towards.  (I'm not going to finish the whole thing until it stands a
chance of getting in 'relatively' quickly, because configure.in is a
seriously moving target.  Although, the fewer dead subdirectories are
in it, the easier it is to keep up to date.)

--Nathanael Nerode
neroden@doctor.moo.mud.org
neroden@twcny.rr.com

Re: toplevel autoconfiscation design questions

[Daniel Jacobowitz]

On Tue, Apr 02, 2002 at 02:21:10PM -0500, Nathanael Nerode wrote:
> I've got fairly complete working autoconfiscations of the toplevel
> directory going several times now.  Several important design choices
> have come up:
> 
> * Should subdir/configure scripts be invoked from the top level
> configure (where it is now), or from the top level Makefile?  (I've
> worked out how to do both.)
> 
> Arguments for the configure script: no locking issues with the cache,
> better documentation of options when & if we move to autoconf2.5x, what
> else?
> 
> Arguments for the Makefile: configuration parallel with other processes,
> don't configure subdirs you aren't using today, what else?

The most important is that many directories can not be configured until
after others are built.  For instance, newlib requires GCC and binutils
to have been built, because it's a target library.

> * Should the logic for ignoring missing subdirectories be in the
> Makefile (where it is now), or in the configure script?
> 
> Arguments for configure: this is really a configure-time issue, it's
> slower and uglier in the Makefile, what else?
> 
> Arguments for Makefile: it's there now, moving it may reveal subtle
> issues, what else?

FWIW (absolutely nothing!) I'd like it in configure.  It would also be
nice to let the user specify which directories to configure, but if
you're going to do that there's a strong argument for moving this and
all subdir configuration to the makefile.

> I'm still held up in actually doing this until my (or someone's) spu
> autoconfiscation patch gets into gdb (since calling Cyngus configure
> from a top level autoconf configure is... undesirable...).

Please post this to the GDB patches list again and I'll see what I can do.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: toplevel autoconfiscation design questions

[Nathanael Nerode]

On Tue, Apr 02, 2002 at 02:30:25PM -0500, Daniel Jacobowitz wrote:
> On Tue, Apr 02, 2002 at 02:21:10PM -0500, Nathanael Nerode wrote:
> > I've got fairly complete working autoconfiscations of the toplevel
> > directory going several times now.  Several important design choices
> > have come up:
> > 
> > * Should subdir/configure scripts be invoked from the top level
> > configure (where it is now), or from the top level Makefile?  (I've
> > worked out how to do both.)
> > 
> > Arguments for the configure script: no locking issues with the cache,
> > better documentation of options when & if we move to autoconf2.5x, what
> > else?
> > 
> > Arguments for the Makefile: configuration parallel with other processes,
> > don't configure subdirs you aren't using today, what else?
> 
> The most important is that many directories can not be configured until
> after others are built.  For instance, newlib requires GCC and binutils
> to have been built, because it's a target library.

Those will of course have to be in the makefile; the question is
regarding the, hmm, 'host' subdirectories, and 'build' subdirectories if
there are any.  So I guess there's also a 'the target subdirs are there,
why not all of them?' argument.

> > * Should the logic for ignoring missing subdirectories be in the
> > Makefile (where it is now), or in the configure script?
> > 
> > Arguments for configure: this is really a configure-time issue, it's
> > slower and uglier in the Makefile, what else?
> > 
> > Arguments for Makefile: it's there now, moving it may reveal subtle
> > issues, what else?
> 
> FWIW (absolutely nothing!) I'd like it in configure.  It would also be
> nice to let the user specify which directories to configure, but if
> you're going to do that there's a strong argument for moving this and
> all subdir configuration to the makefile.
After looking at everything, I don't see a clean way to put *both*
subdir configuration *and* proper treatment of missing directories into
the makefile.  There is probably a very messy way....

--Nathanael Nerode