Re: preventing variable expansion

[Marcus Brinkmann]

On Mon, Sep 22, 2003 at 08:13:54PM +0200, Alexandre Duret-Lutz wrote:
> >>> "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)

Ah, ok.  That works indeed.

[...]

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

I agree that this makes sense, but punting it to configure has disavantages,
too:

- It requires you to rebuild the configure script and reconfigure your tree
  when you add to the list of required routines,
- in fact it requires you to list the required routines at the configure
  level, rather than at the Makefile level only,
- autoconf is not at all modular at the source tree level - if you have
  several more or less independent source directories, you end up lumping
  all the checks for them in a single configure file.  I heard some not so
  nice things about really independent configures in subdirectories (maybe
  this has been fixed), and using included .m4 files has the problem of
  requiring to reconfigure the whole tree.

So, basically, it all boils down to the fact that a configure script is more
something that applies to the tree as a whole, while Makefile.am's are
nicely localized to the subdirectory they are contained in.

Nevertheless, I see your rationale.  I will consider doing that.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    address@hidden
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
address@hidden
http://www.marcus-brinkmann.de/