[Top][All Lists]

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

Re: Compilation flags and variables

From: Ralf Wildenhues
Subject: Re: Compilation flags and variables
Date: Wed, 31 May 2006 11:10:04 +0200
User-agent: Mutt/1.5.11

Hi Guillaume,

* Guillaume Rousse wrote on Wed, May 31, 2006 at 10:38:42AM CEST:
> I read the automake and autoconf manual several times, but I'm still a
> bit uncertain at how to manage compilation flags properly, meaning:
> - which flags to use
> - where to use them

You're going from specialized to general in your list, which is nice,
because it enables me to follow that:

> First, you have per-primary targets options (discarding non-C language
> ones):
> foo_CFLAGS
> foo_(LIBADD|LDADD), for programs and libraries respectively

First rule: don't use foo_DEPENDENCIES unless you have to.  (I think the
examples where you have to are mentioned in the Automake manual.)
Rationale: most of the time, Automake is good to compute the
dependencies itself.

Second rule: don't use any per-target options unless you have to.
There's nothing inherently wrong with them, but they usually make the
resulting Makefile more complicated.

> My understanding of documention is that foo_LIBADD|LDADD) expect either
> real linker options among -l, -L, -dlopen and -dlpreopen, or library
> names such as foo that will automatically get expanded into -lfoo
> -L/path/to/foo, and foo_LDFLAGS expect all other linker flags. I don't
> understand foo_DEPENDENCIES purpose, however.

LIBADD vs LDADD: the former applies only when we *create* a library.

L*ADD vs LDFLAGS: you're pretty much on target:
* ../lib2/ goes always into L*ADD
* -lfoo likewise
* -dlopen .., -dlpreopen .., likewise
* -L/some/dir  is not so clear-cut (it's position-dependent as well.)

Other linker flags that are position-independent go into *LDFLAGS.
(FWIW, general position-dependent linker flags are a TODO item for
Libtool still.)

*_DEPENDENCIES are necessary to override only when, for some reason,
Automake can't compute the dependencies itself.  For example if you
have the list of needed source files only known after configure is run.
This thread has an example of this:

> Then they are per options:
(plus LDADD, I think)

Yes.  They are the default flags to use as the package developer.

> Those are pure-automake ones, and used in place of per-target ones of
> the same name if not defined. AM_(LIBADD|LDADD) and AM_DEPENDENCIES
> don't exists, however.

Right.  The last one would not make so much sense.

> Then they are per-project flags, definable either in or in

Yes.  Except maybe for DEFS, the Automake policy is that all of the
above are reserved for the user (the one who runs configure).
(This does not contradict the fact that, within the script,
you, the developer, may have to muddle with LIBS or others at times for
some test: you typically restore these variables, or assign the test
results to some more specific variables.)

DEFS is mostly used nowadays do contain

when autoheader is used.

> They are always used in addition to previous ones. CFLAGS is exaclty
> similar to AM_CFLAGS, but CPPFLAGS and LDFLAGS are not equivalent to
> their AM_* forms, as the first one is supposed to exclude -D options (to
> be defined in DEFS), and LDFLAGS include all linker flags excepted -l
> ones (to be defined in LIBS).

Yes.  The non-AM_* forms are so the user can override the developer.
(The usage model here is that the developer has no chance of knowing
all system quirks and compiler oddities, so the user gets a way to
work around them.)

> How are you supposed to manage automake vs autoconf flags ? The most
> simpler seems to use preferentially automake-defined variables in
>, and keep autoconf ones in However, this is
> not always possible. Imagine you want to link all programs in a given
> directory with a library, and such you need global linker options (-L
> and -l) for this directory only. The only solution seems to use autoconf
> variables LIBS and LDFLAGS in AM_LDFLAGS isn't supposed to
> accept -L options, and there is no AM_(LIBADD|LDADD).

You can use LDADD.  Or you can define your own variables:
  AC_SUBST([LIBFOO_LIBS], [-L/blabla -lfoo])

and write
  libfoo_la_LIBADD = $(LIBFOO_LIBS)

in the  Or just substitute libfoo_la_LIBADD right away.
An example with LDADD is in the manual.  Many choices here, to adjust to
your specific package.


reply via email to

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