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. Ben ----- Original Message ---- From: Clinton Stimpson <clin...@elemtech.com> To: CMake <cmake@cmake.org> Sent: Tuesday, March 31, 2009 2:15:25 PM Subject: Re: [CMake] autoheader 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 _______________________________________________ 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
