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

[Stephen Kelly]

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

That's something for the future anyway.

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

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

>> 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. I never made any suggestion or reference to 'adding a qmake 
buildsystem to the frameworks'. I don't know why you suggest I made a claim 
like that. I did not make any such claim. There is no such misunderstanding, 
except in the misunderstanding that you just wrote.

> I'm merely installing a .pri file for qmake [users].

Yes.

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

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

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

I don't agree with the claim that there is a contradiction, but I guess I'm 
not writing clearly enough somehow, or we're not talking about the same 
things... 

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

> 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


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

> 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. Somewhat related:

 http://public.kitware.com/Bug/view.php?id=9822

Thanks,

Steve.