On Thursday 16 February 2012, Brad King wrote: > On 2/16/2012 2:24 AM, Alexander Neundorf wrote: > >> cmake_package_config > > > > We have already write_basic_config_version_file(), and I wanted to have > > the > > In hindsight that name was poorly chosen. I'd really like to see "package" > in the name because they are "package configuration files". Otherwise > there is no indication it has anything to do with find_package.
Well, it has to do with Config files :-) > > I was thinking about putting it into a file which may have a different > > name, maybe CMakeConfigHelpers.cmake, which should then also > > include(WriteBasicConfigVersionFile), so you get both when you include > > it. > > The new module could include WriteBasicConfigVersionFile for > convenience. Yes. So which one ? 1) configure_config_file() + write_basic_config_version_file() 2) configure_package_file() + write_basic_config_version_file() 3) configure_package_file() + write_basic_package_version_file() Personally, I prefer 1) and 3) over 2). > >> Good. Did you consider other prefixes? > > > > It should match with the other variable names which are generated, and > > they use the CONFIG_HELPER_ prefix. > > I was asking if *all* the prefixes of generated variables for the entire > config file could use a different prefix, not just the INIT one. If I > read the .in file and do not know what CONFIG_HELPER means I have no > indication that it comes from a magic macro that does not have > CONFIG_HELPER in its name. If the prefix were configurable than "grep" in > the source tree would reveal the origin of the name because it would > appear in the call to the configuration macro. Alternatively if the > prefix were to match part of the macro name it would be clear also. Ok, I can do that. > >> Okay. The set_and_check macro is perhaps overkill. I've never > >> done an explicit existence check on such directories in a package > >> configuration file. > > > > Yes, but I think it's better to do it. > > Sure. Users who don't like it can just not call it. I'd also like an > option to the macro to exclude it from appearing so that my package > configuration files do not add any macros. Ok. I'd go with default on. Alex -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
