Re: Multiple definition of VERSION, PACKAGE and so on

[Guido Draheim]

Patrick Guio wrote:
> On Tue, 23 Mar 2004, Guido Draheim wrote:
>
>
> > > 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).
>
>
> I would definitely like to hear how do you handle the following solution
> if you mean this is TOTAL ERROR to include config.h into header files
> that are made publically available to outside projects.
> As far as now I have a pack1-defs.h header file containing definitions like:
>
> #if defined(HAVE_CONFIG_H)
> #include <pack1-config.h>
> #endif
>
> #if defined(FLOAT_FIELD)
> typedef float pack1Real;
> #elif defined(DOUBLE_FIELD)
> typedef double pack1Real;
> #else
> #error macro FLOAT_FIELD or DOUBLE_FIELD must be defined
> #endif
>
> typedef blitz::Array<pack1Real,1> Array1dr;
> typedef blitz::Array<pack1Real,2> Array2dr;
> typedef blitz::Array<pack3Real,3> Array3dr;
>
> typedef blitz::Array<pack1Real,DIM> Field;
>
> I need to make this file publically available to outside projects if I
> don't want to redefine type Field for example. But to do so I have to
> include pack1-config.h as well since definition FLOAT_FIELD or DOUBLE_FIELD
> needs to be defined.
>
> That's the way we handle definitions in the Blitz++ project as well so if
> you have a better solution let me know!
>
>
>
> > as a solution, instead of current usage, modify pack1/configure.ac to use
> >   AC_CONFIG_HEADER
> >   AX_PREFIX_CONFIG_HEADER([pack1-config.h])
>
>
> This does not work with autoconf-2.59/automake-1.8.3.
>
> % autoreconf -vif
>
> autoreconf: Entering directory `mudfas'
> autoreconf: running: libtoolize --copy --force
> Putting files in AC_CONFIG_AUX_DIR, `config'.
> autoreconf: running: /usr/local/gnu/bin/autoconf --force
> autoreconf: running: /usr/local/gnu/bin/autoheader --force
> autoheader: error: AC_CONFIG_HEADERS not found in configure.ac
> autoreconf: running: automake --add-missing --copy --force-missing
> configure.ac:10: not enough arguments for AC_CONFIG_HEADERS
>
> Still a new configure is generated. But then when running configure
>
> ./configure: line 1580: syntax error near unexpected token
> `src/mudfas-config.h'
> ./configure: line 1580: `AX_PREFIX_CONFIG_HEADER(src/mudfas-config.h)'
>
> It looks like AC_CONFIG_HEADER is enough (whithout S). So you don't need
> to have the whole keyword but a long enough one to be unambiguous?

nope, they are different - I didn't knew the *S word has been made to
actually require an argument. Originally, we had only the version without
an S and only one config header file was expected to be used.

autoconf-2.13]$ grep AC_CONFIG_HEADER *.m4
acgeneral.m4:dnl AC_CONFIG_HEADER(HEADER-TO-CREATE ...)
acgeneral.m4:AC_DEFUN(AC_CONFIG_HEADER,
acgeneral.m4:dnl Support passing AC_CONFIG_HEADER a value containing shell 
variables.
autoheader.m4:define([AC_CONFIG_HEADER], [#


> I have another remark. Is the use of AC_CONFIG_HEADER expected to have the
> same behaviour as passing argument on line? (Because it is not
> necessary the same behaviour as said in an earlier email)

using a macro name without ()-parentheses or empty ()-parentheses
is equivalent. I do not know if that was the question but let that be an
answer right here ;-)

* now, going back to earlier items in the mail
> ./configure: line 1580: syntax error near unexpected token
> `src/mudfas-config.h'
> ./configure: line 1580: `AX_PREFIX_CONFIG_HEADER(src/mudfas-config.h)'

you need to download the ax_prefix_config_header.m4 file and put the
content in your acinclude.m4 - the macro is not (yet) shipped with
core autoconf. The AX* hints for macros from the autoconf macro archive.

> #if defined(HAVE_CONFIG_H)
> #include <pack1-config.h>
> #endif
>
> #if defined(FLOAT_FIELD)
> typedef float pack1Real;
> #elif defined(DOUBLE_FIELD)
> typedef double pack1Real;
> #else
> #error macro FLOAT_FIELD or DOUBLE_FIELD must be defined
> #endif
>
> typedef blitz::Array<pack1Real,1> Array1dr;
> typedef blitz::Array<pack1Real,2> Array2dr;
> typedef blitz::Array<pack3Real,3> Array3dr;
>
> typedef blitz::Array<pack1Real,DIM> Field;


#include <pack1-config.h>

#if defined(PACK1_FLOAT_FIELD)
typedef float pack1Real;
#elif defined(PACK1_DOUBLE_FIELD)
typedef double pack1Real;
#else
#error macro PACK1_FLOAT_FIELD or PACK1_DOUBLE_FIELD must be defined
#endif

With the prefix, there can't be any name clash.

cheers,
-- guido                                  http://AC-Archive.sf.net
GCS/E/S/P C++/++++$ ULHS L++w- N++@ s+:a d(+-) r+@>+++ y++