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

[David Faure]

On Saturday 04 January 2014 23:13:49 Stephen Kelly wrote:
> David Faure wrote:
> > Indeed it might not work with static libs, or on Windows.
> > But AFAICS listing dependent libs isn't supported in this file format, so,
> > tough luck.
> 
> afaik, what you are listing is qmake modules, not libraries.

Well, ideally we would need both.....
For qt5 and kf5, qmake modules.
But for libz.so and libbz2.so, there are no qmake modules, so this would 
require a list of dependent libs too.

> That's why you
> need to list the qt-provided modules, and the kf5-provided-modules. Even
> when you can iterate over the target dependencies of KIOCore, you would need
> a way to identify the qmake module to list. You could test for the
> QMAKE_MODULE_NAME property to identify upstream Qt, but you'd have to add
> and maintain some way to identify KF5 targets which have a corresponding
> qmake module. It's not as simple as 'is it a cmake target', or 'is it an
> imported target'. You need to know whether it's a KF5 imported target or
> not. Maybe you would be satisfied with startswith("KF5::") for that, I
> don't know...

Yes - for the kf5 targets it's easy, they would all have a corresponding qmake 
module with the exact same name as the target.

> >> Personally I'd put more weight into documented uses than asking someone.
> > 
> > http://qt-project.org/wiki/Creating-a-new-module-or-tool-for-Qt#58bc93114d
> > 2386b74e861888ac36a384
> That
> 
> 1) Is a wiki, not the (versioned) qmake manual
> 2) Does not relate to third party uses. It is only for things which are
> 'part of Qt'.

There is no other solution anyway.

> >> By 'adding qmake support', you tie your hands regarding the cmake
> >> features you can use, you double the number of buildsystems that
> >> developers should test their changes with etc. Developers won't test
> >> their changes with multiple buildsystems. It will be easy for developers
> >> to break the qmake files, especially in ways we haven't thought of, and
> >> then time will have to be spent post-hoc fixing them.
> > 
> > No no, I'm not adding a qmake buildsystem to the frameworks.
> 
> I didn't say you were. I said you were adding qmake files, and those files
> can be broken and must be maintained, and must be tested, and won't be
> tested.

Well, they don't need to be tested "when developers make changes".
Changing the code doesn't change anything in these .pri files.
[This is my confusion as to what you meant, came from]

The only issue that has an effect on the .pri files is adding new deps - hence 
your suggestion of grabbing these automatically, which I agree with, but which 
isn't available at the moment.

However a tiny bit of duplication is really no reason to give up - the 
alternative is for all qmake-based apps to duplicate that information, which 
is really a lot worse.
 
> > The only thing that developers have to do is provide the right info for
> > the .pri file, which is really just a lib name and a list of qt5/kf5 deps.
> > Not much that can break there,
> 
> As I wrote, using generator expressions in ways allowed and recommended by
> cmake would make generated qmake files useless/broken (if the qmake files
> are generated in the future). Yes, there is plenty that can break.

The include install dir is always always  
${CMAKE_INSTALL_PREFIX}/${INCLUDE_INSTALL_DIR}/${PRI_TARGET_BASENAME}
There's no need to grab this from the target, I made it consistent in all 
frameworks (for other reasons: consistency).

So the only thing we need to grab from the target (i.e. the only thing that 
could end up with a generation expression) is the list of dependencies, and 
that isn't even available right now. Therefore, I'll write deps explicitely
(this will definitely not be the only place where deps are written down, kde-
build-metadata has them too...), and this issue won't occur.

> > and the qmake-based app developers will
> > catch mistakes if any.
> 
> Yes, post-hoc, after the fact, after release, etc.
> 
> I doubt regular KF5 developers will regularly test it, as I attempted to
> make clear before.

And I agree. So?

Because something can't be perfect we shouldn't do it at all? I would 
disagree.

Especially since I don't expect dependencies to change much after the initial 
release (it would create all sorts of BC issues). So this only needs one good 
testing before the release.

> > There's a world of Qt apps that use qmake, I want them to be able to use
> > frameworks without having to either change their entire buildsystem, or
> > write complicated stuff in .pro files (by complicated I mean that I
> > wouldn't even know how to do that in a way that works on other people's
> > machines).
> 
> It's reasonable to assume a third party using qmake must know how to do that
> though, right? Even if you don't?

No, definitely not.
I have quite some experience with qmake-based build systems, actually,
from working on customer code to my own products (kdsoap, kdreports).
But they don't depend on third-party qt libs, like frameworks will be.
This is something that is definitely not easy to integrate, and providing 
qt_KArchive.pri makes it a lot easier. Or even possible in the first place.

> > I'll make an ECM macro from the stuff I wrote in karchive (see 3b24114a6d,
> > I now use file(GENERATE)).
> 
> +QT. at PRI_TARGET_BASENAME@.defines = @PRI_TARGET_DEFINES@
> 
> stephen at hal:~/dev/build/qtbase/qtbase$ grep -i defines mkspecs/modules-
> inst/qt_lib_network.pri
> QT.network.DEFINES = QT_NETWORK_LIB

What's your point?

> > I'd be happy to hear about how I can do it in a nice way: ideally I'd want
> > to automatically get the "VARIABLE_PREFIX" passed to ecm_setup_version,
> > since I need that to get the version numbers.
> 
> It seems odd to me to use UPPERCASE KARCHIVE_* for those variables instead
> of KArchive_*.

No no, I only need VARIABLE_PREFIX to be able to get 
${${VARIABLE_PREFIX}_VERSION_MAJOR}
For instance ${KARCHIVE_VERSION_MAJOR}, which is where the version number is 
stored.
Everything else uses KArchive_*.

> > I'd also want the same two strings as passed to generate_export_header
> > (e.g. KF5KIOCore and KIOCore).
> 
> Actually, you want a list of binary targets created by the buildsystem, or
> rather, in a particular export-set.

For a higher level of magic than what I'm aiming for, yes, I would.
But we call generate_export_header (and configure_package_config_file)
by hand, why can't we call ecm_generate_pri_file by hand?

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