Config files for frameworks (Was: KArchive for Qt4)

[Alexander Neundorf]

On Tuesday 18 December 2012, Stephen Kelly wrote:
> Alexander Neundorf wrote:
> > As providers of a library we should not enforce how people use CMake,
> > i.e. whether they use the automatic INSTALL_RPATH_USE_LINK_PATH or
> > whether they want to decide manually.
> 
> We can
> 
> * make the common things easy (we don't need to do anything and people can
> use INSTALL_RPATH_USE_LINK_PATH)
> * make the less common things possible (We don't need to do anything and
> don't prevent anyone from reading the LOCATION property and using
> get_filename_component() as you did)
> * Minimise the amount of things we put into the Config files (for
> maintenance, so people don't bother adding 'missing' variables which are
> not useful to the 20+ config files we'll maintain by hand)
> * Encourage people to use idiomatic, modern cmake (so we don't have to
> support imaginary use-cases).

This is IMO not imaginary (as far as any use cases of tier1 libraries actually 
can be non-imaginary right now ;-) ).

At work, we set the RPATH manually. We know the limited number of libraries we 
link against, we want to have full control over the RPATH. I would be 
surprised if we would be the only ones.

I wouldn't even say using INSTALL_RPATH_USE_LINK_PATH is better or more 
modern, it's IMO just more convenient for a big project as KDE is.

> The choice not to pre-caclulate and maintain unused variables in Config
> files is not a choice that enforces how anyone else uses CMake.
> 
> > So the LIBRARY_DIR variable should be provided
> > for that case.
> > 
> >> Not using them is
> >> rare enough that it would be ok to read the LOCATION property from the
> >> imported target instead of setting the variable.
> > 
> > Personally I can't judge whether setting the RPATH manually is used
> > rarely or not. In KDE we do it automatically, but we are looking outside
> > the KDE community now.
> 
> Still though, we need to optimize for KDE-projects, and those are going to
> use the 'KDE cmake settings'.
> 
> That's something we've always done. kde4_add_executable and
> kde4_add_library are already making choices about how the user can use
> cmake with 'KDE stuff'. 

Now that the tier1 libraries are in somewhat good shape, I get a better feel 
for them.
(their Config.cmake files are actually still not complete, they still lack the 
find_package() for the required Qt libraries)

Having said that, I now consider them simple libraries, like qwt or qxt, 
which, if LGPL would not be a problem for us at work, we could simply use like 
any other library. I would be happy then if the library would provide me a 
karchive_LIBRARY_DIR variable, which I can use for the RPATH or not.

... ok, actually, we set the RPATH fix to a location inside our install 
hierarchy, ignoring any other directories.

Another option would be to have 

get_target_property(_tmpSolidLocation KF5::solid LOCATION)
get_filename_component(solid_LIB_DIR ${_tmpSolidLocation} PATH)

in solidConfig.cmake.
This way it wouldn't look like pre-calculated variables.
But, actually if you look into the Targets-<buildtype>.cmake file, 
_IMPORT_PREFIX is also precalculated based on information from cmake time.
So practically, it wouldn't change much.

I mean, why should we not provide it ?
We depend on that the information we have in the Config.cmake file is correct. 
If we are afraid that our calculated solid_LIB_DIR is wrong, then we have a 
bigger problem.

Alex