Non-recursive automake

[Jan Engelhardt-3]

Hi,


when one decides to drive make in a non-recursive fashion, one has to
write an Automake file like this:

lib_LTLIBRARIES = foo/bar.la
foo_bar_la_SOURCES = foo/one.c foo/two.c

Usually I stuff that into a file called "foo/Automakefile" and "include
foo/Automakefile" from the real Makefile.am. Despite being in a
subdirectory, one may not omit foo/; that is ok.

However, it is tiresome. Is there perhaps a way, or a planned
development action, so that one can omit all foo/s inside
foo/Automakefile and have automake automatically add foo/ upon seeing
"include" (or a variant thereof) in the upper Makefile.am?

Also, when subdir-objects is in effect, it will create odd long names
such as foo/foo_bar_la-one.o where at least the foo_ prefix would be
redundant in some cases.



Jan

[Bob Friesenhahn]

On Sat, 17 Oct 2009, Jan Engelhardt wrote:

>
> when one decides to drive make in a non-recursive fashion, one has to
> write an Automake file like this:
>
> lib_LTLIBRARIES = foo/bar.la
> foo_bar_la_SOURCES = foo/one.c foo/two.c
>
> Usually I stuff that into a file called "foo/Automakefile" and "include
> foo/Automakefile" from the real Makefile.am. Despite being in a
> subdirectory, one may not omit foo/; that is ok.
>
> However, it is tiresome. Is there perhaps a way, or a planned
> development action, so that one can omit all foo/s inside
> foo/Automakefile and have automake automatically add foo/ upon seeing
> "include" (or a variant thereof) in the upper Makefile.am?

I complained about this perhaps five years ago since it is the most
annoying issue related to non-recursive build.  There was some
discussion on this list at that time but nothing was done to make
things better.

It seems that a problem is that much of the Makefile.am file is simply
copied to the output Makefile.in and so these parts would need to be
re-written rather than copied.  The good news is that perl is good at
re-writing text.

Bob
--
Bob Friesenhahn
bfriesen@..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

[Robert Collins]

On Sat, 2009-10-17 at 20:09 -0500, Bob Friesenhahn wrote:

>
> I complained about this perhaps five years ago since it is the most
> annoying issue related to non-recursive build.  There was some
> discussion on this list at that time but nothing was done to make
> things better.
>
> It seems that a problem is that much of the Makefile.am file is
> simply
> copied to the output Makefile.in and so these parts would need to be
> re-written rather than copied.  The good news is that perl is good at
> re-writing text.

The way I tackled this in my proof of concept in 2001 was via a
rewriting include:

http://sources.redhat.com/ml/automake/2001-08/msg00112.html

This added a new directive 'subdir_include' which does an include but
adjusts all the paths in the make/automake rules in the included
fragment to the relative path to the included rules.

e.g. subdir_include foo/Makefile.am
would prepend 'foo' to the paths in foo/Makefile.am.

Automake's core has probably changed so much that the patch is not worth
even reading, but the concept worked tolerably well ;).

-Rob

[Ralf Wildenhues]

Hello,

* Jan Engelhardt wrote on Sat, Oct 17, 2009 at 07:04:39PM CEST:

> when one decides to drive make in a non-recursive fashion, one has to
> write an Automake file like this:
>
> lib_LTLIBRARIES = foo/bar.la
> foo_bar_la_SOURCES = foo/one.c foo/two.c
>
> Usually I stuff that into a file called "foo/Automakefile" and "include
> foo/Automakefile" from the real Makefile.am. Despite being in a
> subdirectory, one may not omit foo/; that is ok.
>
> However, it is tiresome. Is there perhaps a way, or a planned
> development action, so that one can omit all foo/s inside
> foo/Automakefile and have automake automatically add foo/ upon seeing
> "include" (or a variant thereof) in the upper Makefile.am?

Yes.  The latest plan I couldn't get stabilized so left out for 1.11:
<http://thread.gmane.org/gmane.comp.sysutils.automake.general/9824/focus=9920>
It would be a good idea to look at it again, though.

> Also, when subdir-objects is in effect, it will create odd long names
> such as foo/foo_bar_la-one.o where at least the foo_ prefix would be
> redundant in some cases.

That might be worth thinking about, yes.  Thanks.

* Bob Friesenhahn wrote on Sun, Oct 18, 2009 at 03:09:08AM CEST:
> I complained about this perhaps five years ago since it is the most
> annoying issue related to non-recursive build.  There was some
> discussion on this list at that time but nothing was done to make
> things better.

Also, your pay check never made it to this side of the ocean.  ;-)

> It seems that a problem is that much of the Makefile.am file is
> simply copied to the output Makefile.in and so these parts would
> need to be re-written rather than copied.  The good news is that
> perl is good at re-writing text.

The bad part is that whenever we rewrite, we introduce a chance to
destroy.  Experience tells me Automake should not rewrite arbitrary
text, that has led to too many problems already.

* Robert Collins wrote on Sun, Oct 18, 2009 at 03:34:20AM CEST:
> The way I tackled this in my proof of concept in 2001 was via a
> rewriting include:
>
> http://sources.redhat.com/ml/automake/2001-08/msg00112.html
>
> This added a new directive 'subdir_include' which does an include but
> adjusts all the paths in the make/automake rules in the included
> fragment to the relative path to the included rules.

The devil is in the details.  What about -I paths in *_CPPFLAGS?  What
with substituted variables?  What about rewritten variable names, such
as: libfoo_la_SOURCES becomes sub_libfoo_la_SOURCES, and what if the
user references $(libfoo_la_SOURCES) elsewhere, say, in
libbar_la_SOURCES?

No.  Search for several prior discussions on the Automake lists for why
this cannot be done safely without highly altering the set of allowed
semantics, and things the user can expect.

Cheers,
Ralf

[Robert Collins]

On Sun, 2009-10-18 at 08:39 +0200, Ralf Wildenhues wrote:

> > http://sources.redhat.com/ml/automake/2001-08/msg00112.html
> >
> > This added a new directive 'subdir_include' which does an include but
> > adjusts all the paths in the make/automake rules in the included
> > fragment to the relative path to the included rules.
>
> The devil is in the details.  What about -I paths in *_CPPFLAGS?  What
> with substituted variables?  What about rewritten variable names, such
> as: libfoo_la_SOURCES becomes sub_libfoo_la_SOURCES, and what if the
> user references $(libfoo_la_SOURCES) elsewhere, say, in
> libbar_la_SOURCES?
>
> No.  Search for several prior discussions on the Automake lists for why
> this cannot be done safely without highly altering the set of allowed
> semantics, and things the user can expect.

I'll take it on faith; I must have missed those discussions (there was a
period while I didn't receive forwarded mail from my old cygwin address
before I resubscribed). Regardless, if something usable is added, +1.

-Rob