Assar Westerlund wrote:
>
> Robert Boehne <[EMAIL PROTECTED]> writes:
> > I have a massive set of C++ libraries that use
> > CVS libtool, autoconf and automake to build and install.
> > Since users then need to have _all_ the header files
> > they also need to have the configure generated config.h
> >
> > What is the "best" way to coerce Automake into installing
> > config.h in $(prefix) ?
>
> I must caution against installing config.h. You will collide with the
> potential same config.h and HAVE* et al defines that the application
> using your header files has figured out for itself.
>
> It's much preferable to make sure that the installed include-files do
> not depend on the autoconf'd parameters in any way. If you really
> need to use the definitions that configure has figured out for you,
> it's much better, I think, to partial-evaluate so that instead of:
>
Thanks everyone for all the input! I'm still in a bind though,
I would prefer NOT to install 12,000 atltered header files for
each platform, the package assumes binaries in a particular location
relative from the source directories, and I do agree that
"config.h" is probably the worst name I could install it as.
So I think the practial "solution" for now is to install
the header in $(prefix) as somthing other than "config.h".
Why? I simply don't have the time or patience to re-arrange
the tens of thousands of source files into a GNU conforming
structure and then convince the maintainers that GNU automake
requires it. People are comfortable with what is familiar,
I don't want to morph this project into somthing that the
originators won't recognize.
I'm gnuing my best here...
--
Robert Boehne Software Engineer
Ricardo Software Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email: [EMAIL PROTECTED]
