ECMGeneratePriFile: Fix static configurations
ClosedPublic

Authored by kfunk on Jan 3 2020, 2:15 PM.

Details

Summary

Populate module_config with staticlib. This is needed for Qt 5.12, as
Makefiles contain the full path to the library instead of just the base
name. QMake needs to be aware of the build type. This issue was found in
KDStateMachineEditor's .pri files.

Before this patch the linker tried to link against .so files even for
static libraries.

Note: Probably not very relevenat to KDE Frameworks (since it's all
about shared libraries, but I'd like to keep the original
ECMGeneratePriFile version up-to-date)

Compare:

% cat kdsme-qmake-test.pro
QT += KDSMEDebugInterfaceSource

!qtHaveModule(KDSMEDebugInterfaceSource): warning("Library not found")

SOURCES += main.cpp

% qmake --version
QMake version 3.1
Using Qt version 5.9.8 in /home/kfunk/devel/build/qt5.9/qtbase/lib
% qmake .
% make
...
g++ -Wl,-rpath,/home/kfunk/devel/build/qt5.9/qtbase/lib ...  -L.../lib -lkdstatemachineeditor_debuginterfacesource ...

% make clean

% env-qt5.12
% qmake --version
QMake version 3.1
Using Qt version 5.12.5 in /home/kfunk/devel/build/qt5.12/qtbase/lib

% qmake .
% make
...
g++ -Wl,-rpath,/home/kfunk/devel/build/qt5.12/qtbase/lib ... .../lib/libkdstatemachineeditor_debuginterfacesource.a ...

Diff Detail

Repository
R240 Extra CMake Modules
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
kfunk created this revision.Jan 3 2020, 2:15 PM
Restricted Application added projects: Frameworks, Build System. · View Herald TranscriptJan 3 2020, 2:15 PM
Restricted Application added subscribers: kde-buildsystem, kde-frameworks-devel. · View Herald Transcript
kfunk requested review of this revision.Jan 3 2020, 2:15 PM
apol accepted this revision.Jan 3 2020, 3:09 PM
This revision is now accepted and ready to land.Jan 3 2020, 3:09 PM
This revision was automatically updated to reflect the committed changes.

This breaks stuff in PIM:

[ 107s] CMake Error at /usr/share/ECM/modules/ECMGeneratePriFile.cmake:183 (get_target_property):
[ 107s] get_target_property() called with non-existent target "KF5AlarmCal".

kossebau added inline comments.
modules/ECMGeneratePriFile.cmake
183

Hmpf, this adds the firm assumption that EGPF_LIB_NAME actually is a target. One could say the API docs require this to be though only implicitly. At least I missed it. And for a reason:

In Okteta I have target names which do not match the outputname. And thus I pass for LIB_NAME the outputname (even extract it explicitely by

get_target_property(_libraryName ${_targetName} OUTPUT_NAME)

so that in the pri file generation code the name and module properties have matching strings. I never looked at the implementation, the TARGET in the helper vars might have hinted me this logic here is more primitive:

set(PRI_TARGET_LIBNAME ${EGPF_LIB_NAME})
# [...]
QT.${PRI_TARGET_BASENAME}.name = ${PRI_TARGET_LIBNAME}
QT.${PRI_TARGET_BASENAME}.module = ${PRI_TARGET_LIBNAME}

Guess I have to come up with a patch to allow caller side to pass another name explicitly then.