On Wed, Apr 1, 2009 at 2:13 PM, BRM <bm_witn...@yahoo.com> wrote:
> Simplicity is best, and I think the simplest solution means not having
> user's bloat their CMakeFiles.txt - it should be part of the system provided
> by CMake.
Let me list the reasons I'm opposed to your proposal of *automatically*
having find modules list preprocessor definitions.
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.
2. 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. Some people may use:
#ifdef HAVE_CURL
while others use
#ifdef USE_CURL
See Google, this is a very common phenomenon. There often is no consistent
agreement on preprocessor definitions to include/exclude additional source
code from being built.
3. 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.
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.
1) Do we want to have a reliable naming convention for variables in the API?
> 2) Do we want to have reliable, cross-project names for the same project in
> the API?
> 3) Do we want to make it easy for users to use the API?
Ultimately I think letting people add whatever preprocessor definitions they
want is the easiest way to solve the problem. The alternative is making
them remove automatically created preprocessor definitions from config.h
they don't want which seems very backwards to me.
Perhaps find_package(), check_library_exists(), etc. could be augmented to
optionally support the autoheader api? 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()
--
Philip Lowman
_______________________________________________
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
