[cmake-developers] Making Config.cmake files easier to write

[Alexander Neundorf]

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