[karchive] /: Show how qmake integration can be done.

[David Faure]

Hi Stephen, thanks for the feedback.

On Saturday 04 January 2014 13:13:47 Stephen Kelly wrote:
> David Faure wrote:
> > Git commit 7948c5cfdf511aef1778681f9fdae96c1cfc14e5 by David Faure.
> > Committed on 04/01/2014 at 11:19.
> > Pushed by dfaure into branch 'master'.
> > 
> > Show how qmake integration can be done.
> > 
> > The .pri.in file should be generated by ECM code instead, to make this
> > easier to deploy.
> 
> Random notes:
> 
> * This should be done with file(GENERATE)

Thanks, that's what I was looking for.

Also, I realized afterwards that it shouldn't be done at the framework level,
but at the library level. E.g. we want QT += KIOCore and QT += KIOWidgets,
not QT += KIO. I'll fix these two things, as a first step.

> * The dependencies should be generated. 'core' should not be hardcoded
> ** Requires implementing http://public.kitware.com/Bug/view.php?id=12435

Yeah, Qt5::Core (as known by cmake) and core (as known by qmake) are not the 
same, and I'm not sure just lowercasing the part after the :: will work for 
all modules - sounds fragile.

> ** Some kind of mapping may be required for the Qt deps. That could possibly
> be encoded in the Qt imported targets.

That sounds like a job for you :)

> ** KF5 deps will have to be listed too of course.

For these, since the .pri file matches the target name (KArchive), a simple 
string manipulation should do.

> > +# This default value makes "installing qt and kf5 into the same prefix"
> > work out of the box. +# Packagers who use -DCMAKE_INSTALL_PREFIX=/usr will
> > certainly want to set ECM_MKSPECS_INSTALL_DIR to something like
> > share/qt5/mkspecs/modules
> 
> Is third party installation of pri files a supported use-case of qmake? Is
> there any reason to think it must continue to work as it does now?

Yes: I asked Oswald before writing all this.

It's the same mechanism as the one used by Qt's own modules, I see no reason 
why it should disappear.

> > @@ -0,0 +1,13 @@
> > +QT. at FRAMEWORK_NAME@.VERSION = @ECM_VERSION_STRING@
> 
> Using the QT namespace is inadvisable. If 'it is required to make this
> work', that would be a strong indicator that you're using unstable internals
> and this should not be done at all.

It is required, but that doesn't mean it shouldn't be done. I quote:

<dfaure> ossi: this only works with QT +=? no way to use another prefix?
<ossi> dfaure: nope. and you really don't want to implement that. ;)

> > +QT. at FRAMEWORK_NAME@.bins =
> 
> Any reason to set this?

No clue, this comes from phonon/qt5_phonon.pri

> It would be wiser to use file(GENERATE) and the
> INTERFACE_INCLUDE_DIRECTORIES target property.

Thanks, I'll do that.
 
> I also notice INTERFACE_COMPILE_DEFINITIONS are not currently added to the
> pri file as <foo>.DEFINES.

OK, will do.

> [sidebar:
>   KArchive should populate the INTERFACE_COMPILE_DEFINITIONS with defines
> corresponding to the built-in support for dependencies.  I should get a
> compile error if my KArchive was not build with lzma, and I attempt to use
> KCompressionDevice::Xz:
> 
>  enum CompressionType {
>  #ifdef KArchive_Built_With_GZip_SUPPORT
>    GZip = 0,
>  #endif
>  #ifdef KArchive_Built_With_BZip2_SUPPORT
>    BZip2 = 1,
>  #endif
>  #ifdef KArchive_Built_With_Lzma_SUPPORT
>    Xz = 2,
>  #endif
>    None = 3
>  };
> ]
> 
> [
> Additional sidebar: The above trick with defines is made possible because
> cmake supports it. qmake also supports it (and inspired the cmake feature).

We could also just generate a karchive-config.h file and install it.
This seems much less "black magic" to me, and much easier to handle with 
different buildsystems. MSVC, ant, a hand-written makefile, etc. will all work 
fine.

When we link to any system lib, we don't have to use the same buildsystem as 
that lib uses itself.

By requiring all frameworks users to use cmake, we reduce the usefulness of 
the frameworks in the first place.

> If the buildsystem is expected (for example) to add defines under certain
> conditions which may be expressed in cmake, but not in qmake, KF5 can not
> make use of such features, because it would break the pri files.
> 
> Consequently, I recommend either:
> 
> 1) Don't add this qmake stuff at all.
> 2) Add it, but do not 'support' it or consider it in any way when making
> choices which affect the cmake buildsystem or features available to
> downstreams which use the frameworks with cmake. Document that this qmake
> stuff is there but may break, be incomplete, be incorrect, or eat kittens.
> Document that only the cmake files are supported and may be expected to work
> and be correct.

And I recommend:
3) Add qmake support, and go easy with the buildsystem magic so that 
application developers can use their buildsystem of choice. Of course we can 
still use advanced cmake features if they make the life of cmake-based 
application developers easier, as long as they don't completely kill the 
support for other buildsystems.

I'm not a qmake fan by far, but I don't want to arbitrarily reduce the user 
base for frameworks just because of the buildsystem.

> > +QT. at FRAMEWORK_NAME@.private_includes =
> > +QT. at FRAMEWORK_NAME@.sources =
> 
> Any reason to set these?

No clue. Taken from phonon.

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