<div class="gmail_quote">On Wed, Apr 1, 2009 at 2:13 PM, BRM <span dir="ltr"><<a href="mailto:bm_witness@yahoo.com" target="_blank">bm_witness@yahoo.com</a>></span> wrote:<br><div></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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.</blockquote><div><br>Let me list the reasons I'm opposed to your proposal of *automatically* having find modules list preprocessor definitions.<br>
<br>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).<br>
<br>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.<br><br>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:<br>#ifdef HAVE_CURL<br>
while others use<br>#ifdef USE_CURL<br>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.<br><br>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.<br><br>
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.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
1) Do we want to have a reliable naming convention for variables in the API?<br>
2) Do we want to have reliable, cross-project names for the same project in the API?<br>
3) Do we want to make it easy for users to use the API?</blockquote><div><br>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.<br>
<br>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.<br>
<br>function(find_package_add_define _pkg)<br> find_package(${_pkg} ${ARGN})<br> cmake_autodefine(... HAVE_${_pkg}) # or what-have-you<br>endfunction()<br></div></div><br>-- <br>Philip Lowman<br>