[Top][All Lists]

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

Re: Are dependency lists statically defined?

From: Ralf Wildenhues
Subject: Re: Are dependency lists statically defined?
Date: Thu, 27 Mar 2008 23:18:39 +0100
User-agent: Mutt/1.5.17+20080114 (2008-01-14)

Hello John,

* John Calcote wrote on Thu, Mar 27, 2008 at 03:03:25PM CET:
> include_HEADERS = file1.h file2.h ... fileN.h
> But very often, these lists will contain shell expansions, like this:
>   added_functionality_a = fileX.h fileY.h
> endif
> include_HEADERS = file1.h file2.h $(added_functionality_a) ... fileN.h

FWIW, this is not a shell expansion, it's an automake conditional which
sets a make variable which is used for setting include_HEADERS.

> Now, here's my question: I've always been under the impression that
> such dependency lists MUST be statically defined for the sake of
> automake. Is this no longer true? Or was it ever true?

Unfortunately, the answer is "it depends".  It depends on the type of
lists whether automake needs to know literal file names, and the type
also makes a difference in "how" literal those names have to be.  The
fact that it depends poses one hidden complexity for Automake users,
and changes to lessen that dependency are very welcome.

Examples on different types of literal-ness:  Assume that 'variable' is
some automake-magic variable (like include_HEADERS, foo_SOURCES, etc).

# completely literal:
variable = foo bar baz
# This works always.

# completely literal, but (conditional) additions:
variable = foo
variable += bar
variable += baz
# This works for almost all stuff (but notably not yet for
# info_TEXINFOS, that's still a TODO item). 

# using variable expansions with variables defined here, literally,
# the variables containing sub-lists:
variable = foo $(helper) baz
helper = bar
# This should work almost always, too.

# using variable expansions with variables defined here, literally,
# the variables containing sub-words:
variable = foo $(subdir)/bar baz
subdir = sub
# This fails for example with dependency tracking and *_SOURCES,
# because the code that generates the stub .deps/foo.Po files is
# really dumb in that it greps the Makefile and thus has no idea
# about variable expansion.

# using variable expansions with substituted variables:
# Here, contains AC_SUBST([helper]).
variable = foo $(helper) baz
# This works often, but not always.  In some cases it is possible
# to get automake to emit the needed rules  with EXTRA_ helpers, for
# example see EXTRA_PROGRAMS in 'info Automake Uniform', or by using
# different magic variables, for example man1_MANS instead of man_MANS
# (with the latter, automake needs to be able to extract the man section
# from the name).

# using shell expansions:
variable = fo*
# This is almost always a bad idea, because if $(variable) ends up in
# some prerequisite list, it will not do the right thing.

# using GNU make-specific expansions:
variable = $(wildcard fo*)
# This works with lists where automake doesn't have to do much except
# know that they exist.  However, one should keep in mind that automake
# can not parse these expansions.

Hope that helps.


reply via email to

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