Re: Non-recursive makefiles

[Olly Betts]

On Wed, May 24, 2006 at 01:57:15PM +0200, Ralf Wildenhues wrote:
> * Olly Betts wrote on Wed, May 24, 2006 at 12:24:53PM CEST:
> > * 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.  :-)

Just to be clear, I'm certainly happy to help but I don't currently know
exactly what the manual should say (if I did I'd have sent a patch to
start with!)

> > * 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).

If .am is used for other purposes, it would probably be better not to
promote the use of arbitrary names ending in ".am" unless there's an
another easy way to determine what a ".am" file is (e.g. from the path
or the contents.)

> >   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.

That probably helps, though the downside is that the whole file fails to be
visible in an editor window sooner.

> >   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.)

For me, I think this partial fix would address most of the issues, but
my project may not be typical, and I've not actually performed a full
conversion yet...

The real problem I can see is that you don't want to pick a partial solution
to the problem now which will later make it hard to provide a fuller
solution.  But if the full problem is deemed too hard to fix, it would
be better to provide at least some improvement.

> 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.

Yeah, I can certainly see it could get hairy.  Maybe limiting what's
allowed in an import-ed file might help?  Hmm, perhaps that's a route
to a partial solution - implement "import" with a lot of restrictions,
and some of these can later be relaxed.

Cheers,
    Olly