[cmake-developers] Making Config.cmake files easier to write
Alexander Neundorf
neundorf at kde.org
Thu Feb 16 10:15:06 EST 2012
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
More information about the cmake-developers
mailing list