[CMake] autoheader

[BRM]

Thanks for the clarifications.

Perhaps my err in this discussion is by referencing the Find functions too generally, and early on too specifically...

Philip Lowman wrote:
1. Just because you call find_package() on a package doesn't mean that
you need a preprocessor definition in your code in order to use it. 
The same is true of checking to see if a function or header file exists
(perhaps just to throw an error if it doesn't).
It is very often these days that one intends merely to build a plugin
by using a 3rd party package in which case adding a global #define via
a config.h file is not wanted at all.

I think that is not really an issue as the modules that do not need to do so simply would do so. This would, of course, have to be done on a module-by-module basis, so the module specific find functions would be the only ones that would be able to make that kind of call. The highly generic functions would have difficulty there.


Philip Lowman wrote:
There is no guarantee that the find module will pick the proper preprocessor
definitions to define if a package is present.  The reason why is that
these vary from project to project.
...

 I think that's the strongest argument against it; but then, wouldn't this be resolved by the package specific find functions (E.g. FindQt4)?
And those functions would just have to worry about changes between versions, which _should_ be (but won't necessarily be) few and far between, no?

So to be clear - the highly generic functions would not necessarily be of use to supporting an autoheader style function internally; but the project specific functions would be able to make good use of it with little to no issue.

Philip Lowman wrote:
It would seem that laying the responsibility of calling
cmake_autoheader() on the find module would limit you to one config.h
header file without really complicating the API.

Again, look at the examples I provided. The user's call to generate the autoheader could be done multiple times for multiple files while the internals to add the variables operated more globally so that any single variable was not added to only one list - but all them. The filtering method (including add and remove) was provided so a user could limit what they got from the list _if_ they chose to, and per someone's suggestion (see list archives).

So again, I think this is a non-issue.

Philip Lowman wrote:
So basically, it might not always be right and it might not always be
wanted.  Not to mention the work involved in retrofitting the find
modules so that they #define the "proper" stuff.

Isn't it easier to do so once for a single project (e.g. cmake as a whole) versus every programmer that wants to use the functionality to have to retrofit their CMakeLists.txt for every little package they want to have autoheader support for? Someone is going to have to retrofit at some point. So why not do it in the most reusable way that minimizes cross-project differences and promotes the most re-use and platform stability?

Philip Lowman wrote:
Perhaps find_package(), check_library_exists(), etc. could be augmented to optionally support the autoheader api?

I think that makes the good sense.

Philip Lowman wrote:
Regardless of whether or not this happens, as Bill pointed out a user
could always use a wrapper function themselves where it makes sense to.
function(find_package_add_define _pkg)
   find_package(${_pkg} ${ARGN})
   cmake_autodefine(... HAVE_${_pkg})  # or what-have-you
endfunction()

I think this should be the project designer's _last_ resort for adding a package; or at the worst a stepping stone while they are waiting on support from CMake provided functions.

Though where users have to, perhaps we could speed things up by providing an easy way for them to provide those functions to CMake for others to benefit from - it'd help generate a series of a project specific functions for it, and alleviate/speed up the work for CMake devs. I'm sure you already have something in place this way for the various CMake script functions, and this wouldn't really be any different - just updating existing ones and adding new ones. The library would grow.

(Summary) So basically - the autoheader stuff for find functions should more or less be only supported by module specific functions - not module independent functions, and we should encourage users (though not require) to send in new support functions or patches for existing functions that don't support it already.

Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20090402/1614278c/attachment-0001.htm>