Re: preventing variable expansion

[Alexandre Duret-Lutz]

Hi Marcus,

Thank for the report and sorry for the delay.

>>> "Marcus" == Marcus Brinkmann <address@hidden> writes:

[...]

 Marcus> routines_objects := $(shell $(NM) --print-armap @STATIC_GLIBC@ \
 Marcus>    2>/dev/null | $(SED) -n -e $(routines_subexp) | $(SORT) -u)

 Marcus> ======================

 Marcus> Now, the obvious thing to do would be:

 Marcus> libc_parts_a_LIBADD = $(routines_objects)

 Marcus> But surprise!  It doesn't work.  automake expands the variable in
 Marcus> Makefile.in, which then contains garbage like

 Marcus> libc_parts_a_LIBADD = $(shell $(NM) --print-armap 2>/dev/null | ...

 Marcus> and so on.  $(routines_subexp) is also expanded.  Note
 Marcus> that @STATIC_GLIBC@ went away, too. 

I assume you meant libc_parts_a_DEPENDENCIES.  This variable is
automatically generated from libc_parts_a_LIBADD by removing
configure substitutions and -l/-L flags.  When that computation
is incorrect, the user is expected to define the variable
himself.  So in your case I presume you should simply write

  libc_parts_a_LIBADD = $(routines_objects)
  libc_parts_a_DEPENDENCIES = $(routines_objects)

 Marcus> automake doesn't like the "linker option" --print-armap
 Marcus> either.

Presently Automake has no support for macro invocations
containing spaces, so it just sees "$(shell", "$(NM)",
"--print-armap", ...  as separate tokens.  That's why it thinks
--print-armap is a linker flag.  One easy workaround is to
quote the flag to fool Automake (e.g., write '--print-armap'
instead of --print-armap).

 Marcus> So I am working around it like this:

 Marcus> routines_varname := routines_objects
 Marcus> libc_parts_a_LIBADD = $($(routines_varname))

 Marcus> Automake is not smart enough to expand this at all,

It's worse than that: it doesn't even realize that this is a
macro expansion (because there are too much parentheses).  So
it copies $($(routines_varname)) to libc_parts_a_DEPENDENCIES as
if it was a filename.

This sounds a bit fragile, though.  If someday Automake decides
to be a bit clever it might realize that $($(routines_varname))
is a variable expansion and try to look for a variable called
"$(routines_varname)" (unsuccessfully).  Upgrading to such a new
version would then cause libc_parts_a_DEPENDENCIES to be defined
empty, introducing a bug which may be hard to spot.

If you go with this solution I suggest you define both

  libc_parts_a_LIBADD = $($(routines_varname))
  libc_parts_a_DEPENDENCIES = $($(routines_varname))

for security.

[...]

 Marcus> If you think the above is ugly, I agree.  If you have
 Marcus> any better idea, that is more in line with what
 Marcus> automake is about, please let me know.

How about computing $(routines_objects) in ./configure?
This sounds cleaner in two ways:
  - nm is not executed each time you run make,
  - this removes these GNU-make-specific things statements
    that Automake fails to deal with.

[...]

-- 
Alexandre Duret-Lutz