[Top][All Lists]

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

Re: using target-specific variables?

From: Harald Dunkel
Subject: Re: using target-specific variables?
Date: Thu, 12 May 2005 13:43:51 +0200
User-agent: Debian Thunderbird 1.0.2 (X11/20050331)

Ralf Wildenhues wrote:
> Hi Harald,
> * Harald Dunkel wrote on Thu, May 12, 2005 at 10:45:40AM CEST:
>>How can I use target-specific variables in Makefiles
>>generated by Automake?
> In general, that is not possible.
> For specific variables, like CFLAGS, CPPFLAGS, you may do this by using
>   target_CFLAGS = ...
> but for the compiler (CC, CXX, ..) this is not implemented.
> Rationale: if you change the compiler, you most likely need to have a
> separate configuration (configure, for it. 

Why would I need a new configure for another compiler?
AFAIR the configure script is supposed to find the settings
for either the compiler I choose, or for the default
compiler. In my case I have 3 compilers, thats all.
It should still be possible to configure these 3 compilers
in parallel.

> That may be
> achieved by using a subpackage (see Automake docs on this subject).

This would mean that I have to manage 2 copies of the
same sources. Hardly acceptable in a development

Anyway, if I introduce a line

        myexe: some_internal_tool_used_at_build_time

then Automake shows the same misbehaviour: It assumes that
I would like to redefine the build rule for myexe. Actually
I just want to list additional dependencies. (I know
myexe_DEPENDENCIES. But the computed default value does
ignore configured libraries, which makes an incremental
build very unreliable.)

Reading sources I found a hint where the
problem is:

# A rule has three parts: a list of targets, a list of dependencies,
# and optionally actions.
  "^($TARGET_PATTERN(?:(?:\\\\\n|\\s)+$TARGET_PATTERN)*) *:([^=].*|)\$";

The comment is wrong. The action is not optional, if you
want to detect whether the author of a would
like to define its own build rule. In this case Automake
has to look at the next line: If it starts with a tab,
_then_ it is safe to assume that the build-in rule should
be ignored.

> There is a workaround, however: you can override the value of CC in a
>  I use this, for example, to invoke a compiler wrapper
> (mpicc) in one subdir, and use the compiler itself in all others.

I have to support a single top level Makefile (thanx to
Miller ;-).

A possible workaround would be to add a pattern matching
suffix rule, e.g.

        %_gcc3.a: CC=gcc3

But this still doesn't solve the problem with myexe.



reply via email to

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