Config files for frameworks (Was: KArchive for Qt4)

[Stephen Kelly]

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).


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'. There's no precedent, reason or requirement to support imaginary 
use-cases.

Let's start with minimal Config files. If we find later (during our 
experience of porting applications to use frameworks) that there's something 
that really really should be in all the Config files, let's add it then.

Thanks,

Steve.