[CMake] cmake config.h

[Clifford Yapp]

To the best of my knowledge, there is no automatic feature available
in CMake for this. Fortunately, it is not terribly hard to set up
something reasonably functional yourself with a few Macros -
autoheader uses some fairly standard naming conventions.  For BRL-CAD
I've wrapped the key tests in macros that check for a filename stored
in some standard global variable (CONFIG_H probably, but I don't
recall) and if that variable does indeed have a filename the macro
appends the appropriate line to the file.  For bonus points, write out
a config.h.in file using (again, IIRC) #cmakedefine lines and then run
configure_file - this ensures the CMakeLists.txt logic gets a chance
to clear out something based on conditionals that a simple
functionality check might include (say, for example, you check for
something on system, find it, and then discover later in the build
logic that the user wants the Boost version, if Boost is found...
usually you can structure to avoid these situations but conceptually
its often simpler to be able to have configure_file pronounce the
"final" judgment on variables at the end of the process.  You can
check the cmake branch of the BRL-CAD svn on sourceforge for an
example; while I make no claim the setup is optimal it does seem to
work.

One thing you won't find (yet) is a library of autoconf-compat
functions to replicate the specialized tests that autoconf provides -
there has been some discussion about that but as yet no concerted,
organized effort to put together a library file.  Hopefully as more
projects undergo this process something will coalesce and even become
standard in CMake.

Cheers and best of luck,
CY

On Fri, Nov 26, 2010 at 10:24 PM, luxInteg <lux-integ at btconnect.com> wrote:
> Greetings,
>
> I am learning cmake.
>
> I have   a package that compiles fine with autoconf but fails with cmake. (The
> former generates automatically  a  required header-file config.h
> ) I have checked the cmake mailing  list to see if the autoheader utility has
> been ported to cmake.  This seems unclear.  So I would be gateful if someone
> on list could  verify if this facility is/isNOT (..yet)  available using
> cmake.  (And if it is -how  it  is used)
>
> sincerely
> luxInteg