[CMake] autoheader

[Philip Lowman]

On Tue, Mar 31, 2009 at 3:27 PM, BRM <bm_witness at yahoo.com> wrote:

>
> Notice my original API suggestion - the project controls its own header -
> just not the list of available items.
>
> So essentially:
>
> 1) Cmake runs, finds packages, builds list
> 2) user add extra items to list
> 3) header generated
>
> Noting from my original API example:
>
> cmake_autoheader(C, path/to/cmake/autoheader_output1.h some_other_package )
> cmake_autoheader(C, path/to/cmake/autoheader_output2.h some_other_package )
> cmake_autoheader(C, path/to/cmake/autoheader_output3.h some_other_package )
>
> Adding in the filtering as I suggested:
>
> cmake_autoheader(C, path/to/cmake/autoheader_output1.h some_other_package
> [filter 1])
> cmake_autoheader(C, path/to/cmake/autoheader_output2.h some_other_package
> [filter 2])
> cmake_autoheader(C, path/to/cmake/autoheader_output3.h some_other_package
> [filter 3])
>
> Each project could easily define its own header (or headers) - there would
> be no limit. And it should probably generate the header immediately based on
> when the cmake_autoheader() is called, based on the state of the list at
> that point. (I think it would be too complex to push it until the end of the
> file; but that might be possible too.)
>
> As to resolving between sub-projects, it would likely be good to internally
> register a scope for the variables - the scope being the path from the root
> CMakeLists.txt to the present one. If a parent, sibling, or child node
> wanted to access a different node's variables, it would have to do so using
> the filters and explicitly name the path. This would be easy to do in the
> filters as the project designer would know the paths between the projects.
> The output in the header would be no different - just the #define
> HAS_VARIABLE no matter what node it was in.
>
> So take the following:
>
> src/CMakeLists.txt
> src/subdir1/CMakeLists.txt
> src/subdir1/subdir1a/CMakeLists.txt
> src/subdir2/CMakeLists.txt
>
> src/subdir1/CMakeLists.txt would be able to access its variables with no
> scoping whatsoever. But to access a variable in src/CMakeLists.txt, it would
> have to provide explicit scoping to it via a filter when generating the
> autoheader via cmake_autoheader(). It would need to do the same to access
> variables in either src/subdir1/subdir1a/CMakeLists.txt and
> src/subdir2/CMakeLists.txt.
>
> However, I would only guarantee that the cmake_autoheader() would be able
> to get what is in the global list at the time it is run. So
> src/subdir1/CMakeLists.txt would likely not be able to see
> src/subdir2/CMakeLists.txt's variables, or all of the variables in
> src/CMakeLists.txt (as some may be defined after src/subdir1/CMakeLists.txt
> is run). It could control what it or its child nodes know though - based on
> when it makes the call, but that can be left to the project designer.


Why not simply make cmake_autoheader() reentrant (and I assume a command)
and have it process last?  This would solve one of your critiques of not
having to pass lists around.  You could also eliminate the need to specify
the filename everywhere and a logical name could be used.  It would
presumably call the functionality provided by configure_file() internally
per logical name.

cmake_autoheader(INIT myconfig ${CMAKE_CURRENT_BINARY_DIR}/config.h)
cmake_autoheader(CONFIG myconfig
      ... stuff like we already have ...)

add_subdirectory(foo)
     foo/ =>  cmake_autoheader(CONFIG myconfig
                ... add additional stuff)

I hear you on trying to automatically add #cmakedefine variables to a list.
Ultimately I think Bill and co. are right that trying to retrofit
find_package() and any other place where you may (or may not) want to add a
#cmakedefine like check_function_exists, etc. is simply going to be too
complex.  Also as for find_package() someone out there will certainly want
HAVE_OPENSCENEGRAPH to work instead of HAVE_OSG or HAVE_OSG2 or whatever.
You seem to like HAS_FOO, others probably prefer USE_FOO or HAVE_FOO_H.
Clearly we're never all going to agree.

Even if it was easy to do this there is another risk.  Users won't care to
really define which variables they want #cmakedefined or not so they'll
simply define everything.  Then you'll end up with what GNU autotools seems
to do now which is to create a ginormous config.h.in file for pretty much
anything you type in configure.ac.  Trying to wade through which of these
#defines are actually necessary or not is an annoying exercise in the use of
grep.  Also many of these #defines are superfluous on modern
compilers/platforms.

-- 
Philip Lowman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20090331/554864fc/attachment.htm>