KArchive for Qt4

[Alexander Neundorf]

On Thursday 15 November 2012, Alexander Neundorf wrote:
> On Thursday 15 November 2012, David Faure wrote:
> > After my presentation on KDE Frameworks at the Dev Days, the obvious
> > question "where do we download this from" came up -- especially for
> > KArchive.
> > 
> > So I took some time afterwards and prepared a self-contained
> > KArchive-for-qt4 release.
> > 
> > This pointed out some interesting issues, especially in the cmakelists. I
> > removed the dependency on ECM, and as a result I saw many things for
> > which I thought "this should be in upstream cmake". Especially the
> > LIB_INSTALL_DIR stuff looks way too complicated to get right without much
> > copy/paste...

What else beside that ?

> > Please take a look at what could be simplified, and test it (I'll try to
> > find people to test it on Mac and Windows, too).
> > 
> > http://www.davidfaure.fr/kde/karchive-qt4.zip
> 
> Actually I can answer this very shortly:
> if you do not want to use on the KDE-style install dir variables, use
> GNUInstallDirs.cmake coming with cmake, it has a similar, but smaller set
> of variables.
> 
> Otherwise, depend on e-c-m (...which should be trivial once we do
> releases).

some more comments:

Why do you include FindLibLZMA.cmake ?
CMake 2.8.9 which you require ships one.

Also, if you don't use the feature_summary() function from 
FeatureSummary.cmake, then you don't have to use set_package_properties().

You use the EXPORT argument in install(TARGETS ...), but don't install the 
generated exports-file nor a KArchiveConfig.cmake file.

Generating a good Config.cmake file is not trivial, as can be seen on the 
lengthy threads about this on kde-frameworks. This is also IMO the most 
significant issue in the buildsystem in the frameworks branch which is still 
far away from its final form.

But seriously, if even you consider e-c-m as too much of a dependency, then we  
can forget about e-c-m completely and just try to upstream everything into 
cmake (not only Stephen and me) and then always depend on the newest cmake 
release available.
But AFAIK this is something we want to avoid. Just last month we had 
discussion when we finally raised the required minimum cmake version to 2.8.8 
(current is 2.8.10).
So, e-c-m is for things which are generally useful, especially not only for 
KDE, but released in a schedule which is better suited to us, it doesn't 
require updating cmake, getting stuff in it is much easier for KDE developers.

Alex