Re: Non-recursive makefiles

[Ralf Wildenhues]

Hi Olly,

* Olly Betts wrote on Wed, May 24, 2006 at 12:24:53PM CEST:
> I've been looking at the feasibility of converting a project (Xapian)
> using autoconf+automake+libtool to using non-recursive makefiles.  

> I'm fairly convinced it'll be an improvement overall, but there are a
> few issues I've noticed so far:
> 
> * Generally, it would be useful for the manual to go into a bit more
>   detail about how to approach all this.

Agreed.  I'm sure Alexandre will gladly accept contributions to
improvement to the manual.  :-)

> * I'm not sure what to call the Makefile.am snippets in the
>   subdirectories.  I looked at GraphicsMagick which was suggested to be
>   a good example in a previous thread and that calls them "Makefile.am".
>   That helps editors know how to syntax highlight, but it feels odd to
>   me and I wonder if it might confuse people to see "Makefile.am"
>   without "Makefile.in", especially if there's an unrelated static
>   "Makefile".

Probably, I've wondered about this before.  You could call it sub.am
or partial.am or similar.  But I'm bad at naming, so I'd rather have 
someone suggest something better.  Wrt editor highlighting: it looks
like Emacs sets type to Makefile for *.am.  For Vim, let's submit a
patch after we've agreed on a good set of names (it sets *.am to
file type Applix ELF if not [mM]akefile.am currently).

>   I also worry that it could confuse the autotools (or may in some
>   future version.)

I dearly hope not.  You're required to list Makefiles that are to be
descended to in SUBDIRS, and Makefiles to be created from Makefile.in's
in AC_CONFIG_FILES, so that should not happen by accident.  But sure, it
doesn't hurt reliability to rename them.

>   Perhaps the automake manual section on non-recursive
>   use (and/or the description of "include") should either bless naming
>   the included snippets "Makefile.am", or recommend a way to name
>   included files?

Yep, good idea.

>   libmain_la_SOURCES += foo/foo.c foo/bar.c foo/baz.c
> 
>   which I think for long lists becomes significantly less readable and
>   harder to maintain.

FWIW, I always write
  libmain_la_SOURCES += \
        foo/foo.c \
        ...

in that case.  And then use block mode to edit the directory prefixes.

>   libmain_la_SOURCES +/= foo.c bar.c baz.c
> 
>   and that would be equivalent to the version above.  "+/=" looks odd
>   but doesn't collide with anything currently valid, and would allow
>   ":/=" and "/=" to do the same magic to ":=" and "=".  I'm not at all
>   wedded to this syntax, it's just the best that's occurred to me so far.

Well, you have to fix include paths and link paths, and all kind of
other stuff too, if you want to make the snippets _really_ ignorant
of their relative inclusion point.  So this would only fix the easiest
bits, really.  (Arguably, that would still be better than what we have
currently.)

>   If this seems a good idea I'm happy to prepare a patch (I've already
>   had a poke around and it shouldn't be too hard to do.)

I remember a comment by Tom Tromey/Alexandre about pondering an "import"
feature: you write
  import snippet.am

and it would strip/add path prefixes "as needed".  The comment went more
or less like this: we've looked at it and decided it was too hard to
solve in general.

> * It would be nice to have a standard feature to generate stub Makefiles
>   in the non-longer-recursed directories which would at least support
>   "make all", "make check", and "make clean".  Ideally these want to be in
>   the build-tree so they're available when srcdir != builddir.  Perhaps
>   it'll be tricky to generate the list of files to clean though?  Or
>   perhaps "make clean" in a subdirectory should clean the whole tree?

Hmm.  If somebody could prove that an "import" feature would be
possible, you could just have a global toplevel Makefile to build all,
and all (or a subset of) sub-Makefiles to build your sub level stuff,
including cleaning and everything.  And all would be synchronized, since
it's all generated from the same source...
I can dream, can't I?  ;-)

Seriously, I currently don't know good solutions to these.  But there is
certainly room for improvement.

One point I would like to tackle soon is the missing subdir-object
support for other languages.

Cheers,
Ralf