How would this global auto header stuff work with two sub projects both
wanting to do auto headers?
Do they share one header, or do they get their own? If they share, what
if they both want a different name for the header file?
Clint
BRM wrote:
Yes, my solution does have a more global variable list. However, I think that
in this case it works to your advantage as you only have to build the list once
and no one has to explicitly know about each list. This makes using a find
function (e.g. FindQt()) easier to write - it just has append to a global list;
and its done. Otherwise, you'd have to prove yet-another-parameter to it so it
could append to your specific list, but then what if you have more than one
list? (e.g. a C header, a CPP header, and a Java header) If you append and pull
from a single list, then all three could get all the information from the same
run; if otherwise you'd have to provide multiple lists to the various find
functions.
The disadvantage with the two lines you proposed is that the builder of the
list - everyone entering something into the list - would have to know about the
file.
Where as the method I proposed, everyone would just add on to the list -
registering to a master list - and then the project designer could pull out
what they want.
It has a simplicity to it.
Drawing the line on how 'global' the list is is another question - though I
would probably make it only as global as the results of any find function would
be. (By this, I mean when moving between CMakeLists.txt input files.)
Personally, I think that if this is going to be done the API needs to be not
just clean, but also elegant. Tacking on another variable to pass in one or
more lists to every single find function so you can have the definitions is not
clean nor elegant. The alternative to allowing Find functions to do the work
for you is to have the user define everything themselves - and that will become
very messy, very quickly especially once people start pulling in other
CMakified projects from other people.
So in this particular case, I think a global list serves the overall need
better, and will result a much nicer and easier to use API.
Just 2 cents for the pot
Ben
----- Original Message ----
From: Bill Hoffman <bill.hoff...@kitware.com>
To: BRM <bm_witn...@yahoo.com>
Cc: Bill Hoffman <bill.hoff...@kitware.com>; CMake <cmake@cmake.org>
Sent: Tuesday, March 31, 2009 12:26:04 PM
Subject: Re: [CMake] autoheader
BRM wrote:
How about:
# Each variable can have a registered filter name - packages/programs/libraries
would use their name
cmake_autoheader_add_variable(has_some_other_package, filter_name)
# user controls what the output file is
# User can generate a C #define method (default method if no language is
specified)
cmake_autoheader(C, path/to/cmake/autoheader_output.h [filter_name_list])
# User can generate a C++ const methods
cmake_autoheader(CXX, path/to/cmake/autoheader_output.hpp [filter_name_list])
- if filter name list is not provided, all entries are entered into the header
file
- if filter is list is provided:
- if name listed and is preceeded by an exclamation (!) then that name is
not entered
- if name is listed then it is entered
- if name is not listed, then it is not entered
Likely it would be good to have a parameter that would specify the default
behavior of the filter list - enter or not enter - for names not listed.
I think a default of 'not enter' would be good if the list is being provided,
and this could be overridden and then the list becomes a 'not enter' list.
So:
# package defines its own automatically
find_package(some package)
if (some_package_found)
-> cmake_autoheader_add_variable(has_some_package, some_package)
...
# user can add it too
cmake_autoheader_add_variable(has_some_other_package, some_other_package)
# user controls what the output file is
# User can generate a C #define method (default method if no language is
specified)
cmake_autoheader(C, path/to/cmake/autoheader_output.h some_other_package)
# User can generate a C++ const methods
cmake_autoheader(CXX, path/to/cmake/autoheader_output.hpp some_package)
just another 2 cents...
I am not sure where things would be stored in this API? Seems to global
Maybe the autoheader should be some sort of target...
cmake_add_autoheader(C /path/to/cmake/autoheader_output.h)
cmake_add_autoheader_variable(/path/to/cmake/autoheader_output.h VAR)
-Bill
_______________________________________________
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
_______________________________________________
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