automake
[Top][All Lists]
Advanced

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

Re: Multiple definition of VERSION, PACKAGE and so on


From: Guido Draheim
Subject: Re: Multiple definition of VERSION, PACKAGE and so on
Date: Tue, 23 Mar 2004 10:02:23 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313



Patrick Guio wrote:
On Mon, 22 Mar 2004, Guido Draheim wrote:



Patrick Guio wrote:

Dear all,
This is not really a bug but I wonder if you have any remedy to the
following problem. If you use autoconf/automake for several packages
which interact with each other and for each package you generate a

     ^^^^^^^^^^^^^^^^^^

configuration file config.h you migh end up with redefinition warning
message if config.h's are read "together".

                      ^^^^^^^^^^^^^^^^^^

... warning: "PACKAGE_VERSION" redefined
... warning: this is the location of the previous definition

... warning: "VERSION" redefined
... warning: this is the location of the previous definition

My concern is how to avoid this? Shouldn't these macro defintion be unique
for each package? Should there be a protection mechanism?


*How* do you let them "interact with each other"?
*Why* are config.h's read together?



What I mean by "interact" is that one package uses on another one :-)
I can give you an example. I have a package pack1 which I have encapsulated
in another one, pack2 (I mean that I have a subdirectory pack2 in pack1
and that configure.ac of pack2 has a AC_CONFIG_SUBDIRS(pack1) command).
I have choosen this architecture since pack2 (plasma simulator) builds on
top of pack1 (pde solver) and pack1 could be used on its own or for other
projects.

Until recently, I didn't use the command AC_CONFIG_HEADERS and I didn't
have any problem since the macros definition -DPACKAGE -DVERSION were
option commands and put just once per compiler command.

Now I wanted to start using AC_CONFIG_HEADERS because I have too many
defs, so I have just a AC_CONFIG_HEADERS([pack1-config.h])
and AC_CONFIG_HEADERS([pack2-config.h]) for each package.
The pack1-config.h is included only if HAVE_CONFIG_H is defined and is
included in my definition file for the package (C++ typedefs for template
arrays (double/float), constant defs, dimensionnality of the problem, MPI
use, FFTW use, HDF use, etc...). Each class declaration and definition
needs this file. The same is done in pack2 but some classes of pack2 uses
public methods of pack1 classes. Therefore in some classes definition of
pack2 I have to include the class declaration of some peculiar classes from
pack1. The result is that the pack1-config.h and pack2-config.h are both 
included.

Now I don't really see how I can avoid that. But you may have suggestions?


As said before - it is TOTAL ERROR to include config.h (here: pack1-config.h)
into header files made publically available to outside projects (here: pack2).

as a solution, instead of current usage, modify pack1/configure.ac to use
  AC_CONFIG_HEADER
  AX_PREFIX_CONFIG_HEADER([pack1-config.h])

have a look at the resulting `pack1-config.h` as the resulting #define's
are named slightly different now (the prefix ye know). Wherever you have
been using autoconfigured #ifdef MYDEFs in your header files, change those
#ifdef PKG_MYDEFs i.e. the new (prefixed) define-names. And all ye problems
will vanish. *plop*

That's it. Good luck, guido                             http://ac-archive.sf.net



Sincerely
Patrick





To answer right away on a frequently asked question: do not install
config.h and do not #include it in public headers of a (sub)project.
Use ax_prefix_config_h to avoid problems with ac_define's
occuring in two autoconfigured header files instead.

btw, -> autoconf people, may be we should move the prefix'config
macro to main autoconf and/or reference it in main documentation?





--
-- guido                                  http://google.de/search?q=guidod
GCS/E/S/P C++/++++$ ULHS L++w- N++@ s+:a d(+-) r+@>+++ y++ 5++X- (geekcode)





reply via email to

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