[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Non-recursive automake
Re: Non-recursive automake
Sun, 18 Oct 2009 08:39:48 +0200
* 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:
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:
> 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
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.