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

[Alexander Neundorf]

On Saturday 04 January 2014, David Faure wrote:
> 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#58bc93114d2
> 386b74e861888ac36a384
> 
> > 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")

I think so.
I'd be even more explicit and add something like "FILE KF5KIOCore.pri", then 
it's clear to the reader what is generated ("FILE" is already used this way in 
install(EXPORT ... ) ).

Alex