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

[David Faure]

On Saturday 04 January 2014 17:18:08 Stephen Kelly wrote:
> [...] and then using $<TARGET_PROPERTY> to read QMAKE_MODULE_NAME.

Yep. But I can't even test this, for lack of http://public.kitware.com/Bug/view.php?id=12435
 
So for now, writing down the list of dependencies will have to do.

> > For these, since the .pri file matches the target name (KArchive), a
> > simple string manipulation should do.
> 
> How will you handle the appearance of third party dependencies?

Good question. It works out of the box on linux with shared libs, so my
qmake-based test (karchive/examples/helloworld) links to libz.so and libbz2.so.

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.

> 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#58bc93114d2386b74e861888ac36a384

> That was a frustrating paragraph to write. It's obvious, and I didn't write
> 'disappear' anywhere...

Sorry about that, I meant disappear or change, indeed. But hopefully the
documentation above will appease your fears.

> 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'm merely installing a .pri file for qmake apps.
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,
and the qmake-based app developers will catch mistakes if any.

> Hopefully that shows for you that the argument is not as simple as 'reducing
> the usefulness of frameworks' if .pri files are not provided.
> 
> I don't buy the argument that usefulness is reduced anyway. Creating and
> installing pri files is not common. qmake users are used to using LIBS +=
> foo and INCLUDEPATH += foo. I don't consider it 'reduced usefulness' to let
> qmake users do the same with KF5 stuff.

This is a contradiction: if there's really not much that one needs, then the .pri file
is very simple and you can't complain that its syntax is too limited.
On the other hand, if there are indeed a lot of additional things needed to use a framework
(loading of dependent libs, and possibly defines) then the usefulness of .pri files is proven...

What I mean is, everything the app would have to do, we can do in the .pri file,
which makes things a lot easier: 
QT += KArchive 
is definitely easier than
INCLUDEPATH += <what do I put here?>/KArchive
LIBS += -lKF5KArchive -L<what do I put here?>/<lib or lib64?>
The qmake file doesn't have to do some sort of configure step, the .pri file is automatically
found and loaded - at most the user has to set $QMAKEPATH if his distro didn't install
the .pri files into the qt  location.

> > 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.
> 
> That's your call, of course.

Thanks. I make the call, then :)

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

I'll make an ECM macro from the stuff I wrote in karchive (see 3b24114a6d, I now use file(GENERATE)).

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.
I'd also want the same two strings as passed to generate_export_header (e.g. KF5KIOCore and KIOCore).
But all these are not stored outside these function calls - and I guess depending on
the order of the function calls is no good.

So I guess it'll have to be something like
 ecm_generate_pri_file(KF5KIOCore BASE_NAME KIOCore VARIABLE_PREFIX KIO DEPS "KCoreAddons KService")

Comments?

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