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

[Alexander Neundorf]

On Thursday 16 February 2012, Alexander Neundorf wrote:
> On Thursday 16 February 2012, Brad King wrote:
...
> > >> 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.


Done (except the renaming).

Before reading on, please have a look at the attached files, especially 
BarConfig.cmake.in.




Actually I expected I would prefer this over the fixed names, but now that 
I've done it and look at what Config.cmake.in file I have to write, I think I 
liked the previous version with the fixed names (CONFIG_HELPER) better. I 
think it was easier to do, a simple scheme.

Before you had to think
"ok, put @CONFIG_HELPER_DIRS_INIT@ at the top, and then use 
@CONFIG_HELPER_+<VariableName>@ instead of @<VariableName>@ in the set() 
commands".

Now you have to think
"ok, put @<MyPrefix>+_HELPER_VARS_INIT@ at the top, and then use 
@<MyPrefix>+_HELPER_+<VariableName>@ instead of @<VariableName>@ in the set() 
commands"

With the fixed names it is probably also better google-able.

What do you think ?

(I wouldn't make setting the prefix optional: either it makes sense, then it 
should always be done, or it does not really make sense, then why should it be 
offered ?)

Alex
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CMakeLists.txt
Type: text/x-cmake
Size: 3229 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20120216/ace4ce86/attachment-0006.bin>
-------------- next part --------------

# set the version of myself
set(BAR_VERSION_MAJOR @BAR_VERSION_MAJOR@)
set(BAR_VERSION_MINOR @BAR_VERSION_MINOR@)
set(BAR_VERSION_PATCH @BAR_VERSION_PATCH@)
set(BAR_VERSION ${BAR_VERSION_MAJOR}.${BAR_VERSION_MINOR}.${BAR_VERSION_PATCH} )

@BAR_HELPER_VARS_INIT@

set_and_check(BAR_INCLUDE_DIR "@BAR_HELPER_INCLUDE_INSTALL_DIR@")
set_and_check(BAR_BIN_DIR     "@BAR_HELPER_BIN_INSTALL_DIR@")
set(BAR_DATA_DIR    "@BAR_HELPER_DATA_INSTALL_DIR@")
set(BAR_BAR_DIR     "@BAR_HELPER_BAR_INSTALL_DIR@")
set(BAR_FOO_DIR     "@BAR_HELPER_FOO_INSTALL_DIR@")

# what is my include directory
set(BAR_INCLUDES "${BAR_INCLUDE_DIR}")

# import the exported targets
include(${CMAKE_CURRENT_LIST_DIR}/BarTargets.cmake)

# set the expected library variable
set(BAR_LIBRARIES bar )
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ConfigureConfigFile.cmake
Type: text/x-cmake
Size: 2576 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20120216/ace4ce86/attachment-0007.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: BarConfig.cmake
Type: text/x-cmake
Size: 1157 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20120216/ace4ce86/attachment-0008.bin>