On Mon, 31 Mar 2003, Dale E Martin wrote:
> Am I not getting some fundamental concept of the intention of config.h
> files?
Yep - see below.
> Here's my problem; I've got several projects that depend on each other;
> several libraries that depend on each other in an orderly fashion. All of
> them are using autotools for their build systems. One of the libraries is
> "clutils", which contains utlilities the other libraries use. As part of
> "make install" clutils is installing it's generated config.h, which has
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Don't do that.
> been named "clutils-config.h". Of course, the next application, "warped",
> definies it's own config.h ("warped-config.h"), and I get warnings when I
> compile:
>
> In older versions of autotools I used to specify not to define "PACKAGE"
> and "VERSION" and this problem went away. I see no way to turn off these
> symbols though, and I'm feeling like I'm missing some fundamental concept
> here.
You shouldn't install config.h: they are not meant to be installed, but
should be used only during the compilation of the project itself. They
shouldn't contain anything of importance to any other application anyway.
If they do, try making a clutils-config.h.in file with the stuff you
*really* need to have in there as variables for use in AC_SUBST, like so:
#define something_I_really_need @SOMETHING_I_REALLY_NEED@
it will be replaced with the value of ${SOMETHING_I_REALLY_NEED} when you
call AC_SUBST(SOMETHING_I_REALLY_NEED) somewhere at an appropriate place
in your configure.{in|ac} file.
Of course, you need to make sure the thing only gets preprocessed once
with the proper
#ifndef _MY_H
#define _MY_H
...
#endif
which config.h lacks - because it's not supposed to be installed anyway :)
HTH
rlc
