changes to how kdepimlibs and kdebase/workspace are installed and found

[Brad King]

Modestas Vainius wrote:
> Hello,
> 
> antradienis 09 Gruodis 2008, Brad King raše.:
>> Many projects have a /usr/lib/<name>[-<version>] directory containing
>> platform-specific data for the package.
> Some do, some do not.
> 
>> Placement of the files near to the libraries in the installation is a
>> *feature* of the find_package command. 
> /usr/lib/liba.so.1.0.0
> /usr/lib/liba.so.1
> /usr/lib/liba.so
> /usr/lib/A/cmake/AConfig.cmake
> 
> /usr/lib/libb.so.2.0.0
> /usr/lib/libb.so.2
> /usr/lib/libb.so
> /usr/lib/B/cmake/BConfig.cmake
> 
> now multiply this by the number of libraries usually installed on the system. 
> Sorry, but I call this /usr/lib pollution. You may not be violating FHS but 
> you're sort of violating spirit of it. What saves the day a bit is that 
> /usr/lib/liba.so /usr/lib/A/cmake/AConfig.cmake can stay in the development 
> package which end users usually do not have installed.
> 
>> It avoids all problems with
>> multiple installations and multiple versions.
> It may be, but at least the current KDE solution does not support development 
> stuff of multiple versions under the same prefix.
> 
>> The command magically
>> finds the files burried in the installation instead of in some central
>> place which can have conflicts.
> instead of <prefix>/(share|lib)/<name>*/(cmake|CMake)/ you can also search for 
> <prefix>/(share|lib)/cmake/<name>*/ or <prefix>/(share|
> lib)/cmake/<name>*Config.cmake. No conflicts.
> 
> 
>> Furthermore, the relative path from the
>> config files to the libraries remains fixed no matter where the package
>> is installed.
> Yeah, it also remains fixed if you use:
> /usr/lib/liba.so.1.0.0
> /usr/lib/liba.so.1
> /usr/lib/liba.so
> /usr/lib/cmake/A/AConfig.cmake or just /usr/lib/cmake/AConfig.cmake
> 
> after s#/usr/lib/##
> 
> liba.so.1.0.0
> liba.so.1
> liba.so
> cmake/A/AConfig.cmake or just cmake/AConfig.cmake
> 
> Looks pretty fixed to me.
> 
> So I really want find_package() to support /usr/lib/cmake search path as an 
> alternative search path. Please give distributors a choice.

When I first designed the find_package search procedure I proposed

   <prefix>/(share|lib)/cmake/<name>*

(see http://www.cmake.org/Bug/view.php?id=3659, 2006-08-25 10:04)

just as you suggest.  The idea was that packages that already have a 
lib/<name> directory can put all their files together (including the 
cmake related files), but others can use lib/cmake/<name>* if they 
prefer.  Later Alex convinced me that providing two places is confusing.

I agree that cluttering /usr/lib with directories just for this one 
purpose is not pretty.  I'll look at updating CMake to search the above 
locations too.

-Brad