[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Non-recursive makefiles

From: Ralf Wildenhues
Subject: Re: Non-recursive makefiles
Date: Wed, 24 May 2006 13:57:15 +0200
User-agent: Mutt/1.5.11

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 snippets in the
>   subdirectories.  I looked at GraphicsMagick which was suggested to be
>   a good example in a previous thread and that calls them "".
>   That helps editors know how to syntax highlight, but it feels odd to
>   me and I wonder if it might confuse people to see ""
>   without "", especially if there's an unrelated static
>   "Makefile".

Probably, I've wondered about this before.  You could call it
or 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] 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'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 "", 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

>   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

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]