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

[Stephen Kelly]

David Faure wrote:

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

Agreed ...

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

... I meant something like this:

diff --git a/mkspecs/features/data/cmake/Qt5BasicConfig.cmake.in 
b/mkspecs/features/data/cmake/Qt5BasicConfig.cmake.in
index dce981e..1f3b3b1 100644
--- a/mkspecs/features/data/cmake/Qt5BasicConfig.cmake.in
+++ b/mkspecs/features/data/cmake/Qt5BasicConfig.cmake.in
@@ -204,6 +204,8 @@ if (NOT TARGET Qt5::$${CMAKE_MODULE_NAME})
     set_property(TARGET Qt5::$${CMAKE_MODULE_NAME} PROPERTY FRAMEWORK 1)
 !!ENDIF
 
+    set_property(TARGET Qt5::$${CMAKE_MODULE_NAME} PROPERTY 
QMAKE_MODULE_NAME $${MODULE})
+
     set_property(TARGET Qt5::$${CMAKE_MODULE_NAME} PROPERTY
       INTERFACE_INCLUDE_DIRECTORIES 
${_Qt5$${CMAKE_MODULE_NAME}_OWN_INCLUDE_DIRS})
     set_property(TARGET Qt5::$${CMAKE_MODULE_NAME} PROPERT

and then using $<TARGET_PROPERTY> to read QMAKE_MODULE_NAME. 

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


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

Personally I'd put more weight into documented uses than asking someone.

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

'Disappear' is not the same as 'continue to work as it does now'. The latter 
is a source compatibility issue. 

The generation and handling of pri files will change over time. The use and 
content of the files in Qt can change because Qt modules can be changed with 
it. If such changes break the KF5 .pri files, then tough luck? Or ossi said 
he'd provide source compatibility to make sure the KF5 .pri files continue 
to work without changes? The significant distinction is that KF5 is third 
party. Qt modules version 5.x.y depend on qt{core/base} 5.x.y, so source 
compatibility is not an issue.

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

>> It would be wiser to use file(GENERATE) and the
>> INTERFACE_INCLUDE_DIRECTORIES target property.
> 
> Thanks, I'll do that.

Note that if you do, you have to ensure that no KF5 module uses a generator 
expression in target_include_directories(foo {INTERFACE,PUBLIC} ...) or 
otherwise populates the INTERFACE_INCLUDE_DIRECTORIES with a generator 
expression.

You have to ensure that only the lowest common denominator of what will work 
in .pri files and Targets.cmake files is ever used.

>> I also notice INTERFACE_COMPILE_DEFINITIONS are not currently added to
>> the pri file as <foo>.DEFINES.
> 
> OK, will do.

Ditto the cautions above.

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

*shrug*. In the case under discussion, perhaps. That is not necessarily the 
end of the story.

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

Correct. However, sometimes our external deps document that 'if you want 
this feature set that define'. They document that because they have no way 
to encode it into the buildsystem we use. Partly that's because they don't 
use the same buildsystem we do, and partly it's because they make no 
expectation/requirement of the buildsystem we use. 

In the KF5 case, the situation is different. Throughout the KDE4 lifetime, 
the only buildsystem supported for third parties to use was cmake. You are 
expanding that to also include qmake (and MSVC, ant, hand written 
makefiles?). That ties your hands with regard to using cmake features and 
forces you to ensure that only lowest-common-denominator features are used 
in KF5. 

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

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.

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. 


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

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

Again, I don't buy this argument.

It's your call. I'm just giving feedback, cautions and recommendations :).

Thanks,

Steve.