KArchive for Qt4

[David Faure]

On Thursday 15 November 2012 21:53:19 Alexander Neundorf wrote:
> 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 ?

Only that and the code below, which I suppose would also be solved by using 
GNUInstallDirs.cmake?

set(INSTALL_TARGETS_DEFAULT_ARGS  RUNTIME DESTINATION "${BIN_INSTALL_DIR}"
                                  LIBRARY DESTINATION "${LIB_INSTALL_DIR}"
                                  ARCHIVE DESTINATION "${LIB_INSTALL_DIR}" 
COMPONENT Devel )
# on the Mac support an extra install directory for application bundles
if(APPLE)
  set(INSTALL_TARGETS_DEFAULT_ARGS  ${INSTALL_TARGETS_DEFAULT_ARGS}
                                    BUNDLE DESTINATION "${BUNDLE_INSTALL_DIR}" 
)
endif(APPLE)


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

Perfect, for such a simple "functional" framework (no plugins, etc.)
 
> > Otherwise, depend on e-c-m (...which should be trivial once we do
> > releases).

Yes, exactly. I only wanted to port karchive-qt4 away from ECM because ECM 
isn't released yet, and I didn't want to release it when I know you guys still 
want to change many things in there.

> some more comments:
> 
> Why do you include FindLibLZMA.cmake ?
> CMake 2.8.9 which you require ships one.

Ah, I didn't know that. I'll remove it from kdelibs-frameworks then, too -- 
this is where this comes from.

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

Oops, oversight.

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

I'm fine with not providing this. The goal of this early release is to ship the 
code, people can then integrate it into their (commercial or opensource) apps.
I'm not sure if karchive-qt4 should be a separate package installed by the 
next version of all linux distros. This is why I started this thread, in fact 
-- to get feedback on this question.
But if our buildsystem isn't ready for that, I'm pretty sure that's "good 
enough" for the people who requested such a package. They will either port it 
to qmake, or they already use cmake anyway and can merge that into their tree, 
or they can write a quick FindKArchiveQt4.cmake. OK I agree none of this is 
ideal, but again -- if this part of KF5 isn't ready, then the proper fix is for 
later.

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

Wait! I never said this. Please understand the difference between "a November 
2012 early release of karchive for Qt4, to satisfy immediate needs", and "a 
proper release of all of KF5, somewhen in 2013, with frameworks that depend on 
each other -- and therefore a very good reason for ECM".

It is definitely not my intention to "kill ECM" -- and I disagree with the 
commit that you made after Sune's comments, in threadweaver.
We have to balance "easy to use for app developers" with "easy to write for 
framework developers". Not using ECM macros means writing a LOT more 
boilerplate code, which means a lot more unmaintainable copy/paste between 
frameworks, and a lot more changes to get things wrong.

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

Yep. And I haven't changed my mind about this.

KF5 will depend on Qt5 and ECM.
karchive-qt4 is a quick hack that depends on Qt4 only, but not the long-term 
solution.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5