Re: autoconfiscation -- questions about make usage

[Nathanael Nerode <neroden at doctormoo dot dyndns dot org>]

On 30 Jan 2002, Alexandre Oliva wrote:

> On Jan 30, 2002, Nathanael Nerode <neroden@doctormoo.dyndns.org> wrote:
> > This means I am probably going to be writing a small program to
> > automatically generate Makefile.in, because there will be huge
> > lists of almost identical targets (which could be collapsed with pattern
> > rules, but not suffix rules).
> 
> Care to explain in advance what kind of targets you're thinking of
> generating?  Perhaps we could help save you some work, should someone
> think of a way to do it without needing such a program.

Sorry, I finally got around to this.  Here's more information than you
asked for.

The repetitive targets are entirely due to one thing: causing the
subconfigures to be invoked by the Makefile rather than the top-level
configure. (This is a feature which was requested by someone.  It's also
the easiest way to do things as long as AC_CONFIG_SUBDIR is broken, which
it is in autoconf 2.13)

First of all, the existing all-$(subdir) targets would have a new
dependency configure-$(subdir).

(if expanded, they'd look like this:
all-misc: configure-misc
	cd misc; $(MAKE) all
check-misc: configure-misc
	cd misc; $(MAKE) check
)

And now the new repetitive targets:
(Note that srcdir_abs is a version of srcdir which will be accurate when
in the subdirectory -- has to be constructed by configure)
(subconfigure_args are the arguments which should be passed to
subconfigures -- must be set by configure)

configure-misc: misc/Makefile
misc/Makefile: config.status
	cd misc; ${srcdir_abs}/misc/configure ${subconfigure_args}

This combination will force misc to be reconfigured precisely when the top
level has been reconfigured.  When something else has changed *within* the
misc directory, the Makefile in the misc directory will deal with any
problems.

I think this is a moderately elegant piece of glue code.  It depends on
misc/Makefile being a *real* target, however.

It can probably be converted into a single Makefile entry rather than one
per subdirectory by (ab)use of macros, much like the other
entries in Makefile.in.  I'd rather not do this as it makes the code much
more unreadable, and significantly slower.  (If I had my way, much of the
nonsense in the existing targets would also go away in favor of a more
explicit Makefile.)  

But if I *did* do this, I'd run into a subtler problem: the current
targets handle missing subdirectories by checking inside the
make code and only doing stuff if the subdirectory is present.  The use of
the real target misc/Makefile makes this impossible.  

The 'missing directory' checks can be moved configure-side.  Putting them
configure-side essentially solves this problem -- at
the expense of requiring 'configure' to take the list of subdirectories,
and generate the lists of 'all-subdir' targets, 'check-subdir' targets,
'configure-subdir' targets, 'subdir/Makefile' targets, and so on.  Using
'sed' or large shell loops.

This should, in fact, work without requiring an additional 'stage'.

But it leaves the slow, unreadable shell script fragments in the
Makefile.in, and adds two more (!).  And it's incredibly wasteful to use
the list of subdirectories in the configure to generate several lists of
targets, and then in each target to jump through hoops to get the original
subdirectory name back.  And this ends up moving some logic which 
belongs in the Makefile (such as which targets support 'check') out of the
Makefile into configure.

All of these disgusting things could be avoided:
* trivially with (implicit) pattern rules (as opposed to suffix rules)
* almost trivially with gcc's static pattern rules
* with an appropriate set of new automake rules (I haven't worked out
precisely how to write them, since I don't yet grok automake)
* with a Makefile preprocessor which converted static
pattern rules (with non-wildcard targets) into individual rules

Moving the non-existent-directory checks into configure may (or may
not) be a good idea anyway.  If you think it's a good idea anyway, then
the asterisked items above would still speed up the Makefile and make it
much more readable, although they wouldn't avoid the heavy string-munging
in configure.

--Nathanael Nerode