AuroraMiddleware/qt5base-lts
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
7b04e0012b
qt5base-lts/cmake/QtFindWrapHelper.cmake

83 lines
3.8 KiB
CMake
Raw Normal View History

CMake: Allow building bundled 3rd party libraries in qtbase A few things are needed to accomplish that: - the python scripts do not ignore certain system_foo features anymore (it is a hardcoded list for now just to be safe) - configurejson2cmake now outputs qt_find_package(WrapSystemFoo) calls for bundled libraries (see below) - the harfbuzz .pro file is modified to accommodate pro2cmake not being able to correctly parse some conditional scopes - the freetype .pro file is modified to make sure linking of the library succeeds without duplicate symbol errors, which qmake doesn't encounter due to magical exclusion of cpp files that are included in other cpp files (presumably for include moc_foo.cpp support) - feature evaluation for Core, Gui, Network now happens in the qtbase/src directory, so that bundled libraries can be conditionally built - for each bundled library there are now two FindWrap scripts: - FindWrapSystemFoo which finds an installed library in the system - FindWrapFoo which either uses the system installed library or the built bundled one depending on a condition - projects that intend to use bundled libraries need to link against WrapFoo::WrapFoo instead of WrapSystemFoo::WrapSystemFoo targets (this is handled by pro2cmake). Unfortunately manually added qt_find_package(WrapFoo) calls might still be needed as is the case for WrapFreetype and others. - a new cmake/QtFindWrapHelper.cmake file is added that provides a macro to simplify creation of WrapFoo targets that link against a bundled or system library. The implementation is fairly ugly due to CMake macro constraints, but it was deemed better than copy-pasting a bunch of almost identical code across all FindWrapFoo.cmake files. - a qtzlib header-only module is now created when using bundled zlib, to provide public syncqt created headers for consumers that need them. These are projects that have 'QT_PRIVATE += zlib-private' in their .pro files (e.g. qtimageformats, qtlocation, qt3d, etc.) This is unfortunately needed due to QtNetwork using zlib types in its private C++ API. The change includes support for building the following bundled libraries: - zlib - libpng - libjpeg - Freetype - Harfbuzz-ng - PCRE2 The following 3rd party libraries are still using an old implementation within the CMake build system, and should be migrated to the new one in the near future: - double-conversion - Old harfbuzz The are a few libraries that are not yet ported: - system-sqlite - systemxcb - maybe others Among other things, this change allows building qtbase on Windows without requiring vcpkg. Task-number: QTBUG-82167 Change-Id: I35ecea0d832f66c1943c82e618de4a51440971a5 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
2020-02-14 13:53:28 +00:00
# Creates an imported wrapper target that links against either a Qt bundled package
# or a system package.
#
# Used for consuming 3rd party libraries in Qt.
#
# Example: Creates WrapFreetype::WrapFreetype linking against either
# Qt6::BundledFreetype or WrapSystemFreetype::WrapSystemFreetype.
#
# The implementation has to use a unique prefix in each variable, otherwise when WrapFreetype
# find_package()s WrapPNG, the nested call would override the parent call variables, due to macros
# using the same scope.
macro(qt_find_package_system_or_bundled _unique_prefix)
set(_flags "")
set(_options
FRIENDLY_PACKAGE_NAME
WRAP_PACKAGE_TARGET
WRAP_PACKAGE_FOUND_VAR_NAME
BUNDLED_PACKAGE_NAME
BUNDLED_PACKAGE_TARGET
SYSTEM_PACKAGE_NAME
SYSTEM_PACKAGE_TARGET
)
set(_multioptions "")
cmake_parse_arguments("_qfwrap_${_unique_prefix}"
"${_flags}" "${_options}" "${_multioptions}" ${ARGN})
# We can't create the same interface imported target multiple times, CMake will complain if we
# do that. This can happen if the find_package call is done in multiple different
# subdirectories.
if(TARGET "${_qfwrap_${_unique_prefix}_WRAP_PACKAGE_TARGET}")
set(${_qfwrap_${_unique_prefix}_WRAP_PACKAGE_FOUND_VAR_NAME} ON)
return()
endif()
set(${_qfwrap_${_unique_prefix}_WRAP_PACKAGE_FOUND_VAR_NAME} OFF)
CMake: Handle conditions in third party find modules correctly Previously the FindWrap modules checked for hardcoded features when deciding whether to use a bundled library or not. This proved not to work correctly because features were not available when the find modules were processed. Introduce a new CMake API call that needs to be manually called after an add_subdirectory call which declares a bundled library. The call will check for the existence of the bundled target, and will then set a cache variable QT_USE_BUNDLED_Bundled<TargetName>. The same variable is written into a FindWrapFooConfigExtra.cmake file which will be loaded by the appropriate FindWrap module. The module can that use that variable to decided whether to link against the bundled library or the system library. Change-Id: I75e9a4f4e14d88d4490916a79ad12f1ce57891e0 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2020-03-05 12:15:34 +00:00
include("FindWrap${_qfwrap_${_unique_prefix}_BUNDLED_PACKAGE_TARGET}ConfigExtra" OPTIONAL)
if(NOT DEFINED "QT_USE_BUNDLED_${_qfwrap_${_unique_prefix}_BUNDLED_PACKAGE_TARGET}")
message(FATAL_ERROR
"Can't find cache variable "
"QT_USE_BUNDLED_${_qfwrap_${_unique_prefix}_BUNDLED_PACKAGE_TARGET} "
"to decide whether to use bundled or system library.")
endif()
if("${QT_USE_BUNDLED_${_qfwrap_${_unique_prefix}_BUNDLED_PACKAGE_TARGET}}")
CMake: Allow building bundled 3rd party libraries in qtbase A few things are needed to accomplish that: - the python scripts do not ignore certain system_foo features anymore (it is a hardcoded list for now just to be safe) - configurejson2cmake now outputs qt_find_package(WrapSystemFoo) calls for bundled libraries (see below) - the harfbuzz .pro file is modified to accommodate pro2cmake not being able to correctly parse some conditional scopes - the freetype .pro file is modified to make sure linking of the library succeeds without duplicate symbol errors, which qmake doesn't encounter due to magical exclusion of cpp files that are included in other cpp files (presumably for include moc_foo.cpp support) - feature evaluation for Core, Gui, Network now happens in the qtbase/src directory, so that bundled libraries can be conditionally built - for each bundled library there are now two FindWrap scripts: - FindWrapSystemFoo which finds an installed library in the system - FindWrapFoo which either uses the system installed library or the built bundled one depending on a condition - projects that intend to use bundled libraries need to link against WrapFoo::WrapFoo instead of WrapSystemFoo::WrapSystemFoo targets (this is handled by pro2cmake). Unfortunately manually added qt_find_package(WrapFoo) calls might still be needed as is the case for WrapFreetype and others. - a new cmake/QtFindWrapHelper.cmake file is added that provides a macro to simplify creation of WrapFoo targets that link against a bundled or system library. The implementation is fairly ugly due to CMake macro constraints, but it was deemed better than copy-pasting a bunch of almost identical code across all FindWrapFoo.cmake files. - a qtzlib header-only module is now created when using bundled zlib, to provide public syncqt created headers for consumers that need them. These are projects that have 'QT_PRIVATE += zlib-private' in their .pro files (e.g. qtimageformats, qtlocation, qt3d, etc.) This is unfortunately needed due to QtNetwork using zlib types in its private C++ API. The change includes support for building the following bundled libraries: - zlib - libpng - libjpeg - Freetype - Harfbuzz-ng - PCRE2 The following 3rd party libraries are still using an old implementation within the CMake build system, and should be migrated to the new one in the near future: - double-conversion - Old harfbuzz The are a few libraries that are not yet ported: - system-sqlite - systemxcb - maybe others Among other things, this change allows building qtbase on Windows without requiring vcpkg. Task-number: QTBUG-82167 Change-Id: I35ecea0d832f66c1943c82e618de4a51440971a5 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
2020-02-14 13:53:28 +00:00
set(${_unique_prefix}_qt_package_name_to_use
CMake: Handle conditions in third party find modules correctly Previously the FindWrap modules checked for hardcoded features when deciding whether to use a bundled library or not. This proved not to work correctly because features were not available when the find modules were processed. Introduce a new CMake API call that needs to be manually called after an add_subdirectory call which declares a bundled library. The call will check for the existence of the bundled target, and will then set a cache variable QT_USE_BUNDLED_Bundled<TargetName>. The same variable is written into a FindWrapFooConfigExtra.cmake file which will be loaded by the appropriate FindWrap module. The module can that use that variable to decided whether to link against the bundled library or the system library. Change-Id: I75e9a4f4e14d88d4490916a79ad12f1ce57891e0 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2020-03-05 12:15:34 +00:00
"Qt6${_qfwrap_${_unique_prefix}_BUNDLED_PACKAGE_NAME}")
CMake: Allow building bundled 3rd party libraries in qtbase A few things are needed to accomplish that: - the python scripts do not ignore certain system_foo features anymore (it is a hardcoded list for now just to be safe) - configurejson2cmake now outputs qt_find_package(WrapSystemFoo) calls for bundled libraries (see below) - the harfbuzz .pro file is modified to accommodate pro2cmake not being able to correctly parse some conditional scopes - the freetype .pro file is modified to make sure linking of the library succeeds without duplicate symbol errors, which qmake doesn't encounter due to magical exclusion of cpp files that are included in other cpp files (presumably for include moc_foo.cpp support) - feature evaluation for Core, Gui, Network now happens in the qtbase/src directory, so that bundled libraries can be conditionally built - for each bundled library there are now two FindWrap scripts: - FindWrapSystemFoo which finds an installed library in the system - FindWrapFoo which either uses the system installed library or the built bundled one depending on a condition - projects that intend to use bundled libraries need to link against WrapFoo::WrapFoo instead of WrapSystemFoo::WrapSystemFoo targets (this is handled by pro2cmake). Unfortunately manually added qt_find_package(WrapFoo) calls might still be needed as is the case for WrapFreetype and others. - a new cmake/QtFindWrapHelper.cmake file is added that provides a macro to simplify creation of WrapFoo targets that link against a bundled or system library. The implementation is fairly ugly due to CMake macro constraints, but it was deemed better than copy-pasting a bunch of almost identical code across all FindWrapFoo.cmake files. - a qtzlib header-only module is now created when using bundled zlib, to provide public syncqt created headers for consumers that need them. These are projects that have 'QT_PRIVATE += zlib-private' in their .pro files (e.g. qtimageformats, qtlocation, qt3d, etc.) This is unfortunately needed due to QtNetwork using zlib types in its private C++ API. The change includes support for building the following bundled libraries: - zlib - libpng - libjpeg - Freetype - Harfbuzz-ng - PCRE2 The following 3rd party libraries are still using an old implementation within the CMake build system, and should be migrated to the new one in the near future: - double-conversion - Old harfbuzz The are a few libraries that are not yet ported: - system-sqlite - systemxcb - maybe others Among other things, this change allows building qtbase on Windows without requiring vcpkg. Task-number: QTBUG-82167 Change-Id: I35ecea0d832f66c1943c82e618de4a51440971a5 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
2020-02-14 13:53:28 +00:00
set(${_unique_prefix}_qt_package_target_to_use
CMake: Handle conditions in third party find modules correctly Previously the FindWrap modules checked for hardcoded features when deciding whether to use a bundled library or not. This proved not to work correctly because features were not available when the find modules were processed. Introduce a new CMake API call that needs to be manually called after an add_subdirectory call which declares a bundled library. The call will check for the existence of the bundled target, and will then set a cache variable QT_USE_BUNDLED_Bundled<TargetName>. The same variable is written into a FindWrapFooConfigExtra.cmake file which will be loaded by the appropriate FindWrap module. The module can that use that variable to decided whether to link against the bundled library or the system library. Change-Id: I75e9a4f4e14d88d4490916a79ad12f1ce57891e0 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2020-03-05 12:15:34 +00:00
"Qt6::${_qfwrap_${_unique_prefix}_BUNDLED_PACKAGE_TARGET}")
CMake: Allow building bundled 3rd party libraries in qtbase A few things are needed to accomplish that: - the python scripts do not ignore certain system_foo features anymore (it is a hardcoded list for now just to be safe) - configurejson2cmake now outputs qt_find_package(WrapSystemFoo) calls for bundled libraries (see below) - the harfbuzz .pro file is modified to accommodate pro2cmake not being able to correctly parse some conditional scopes - the freetype .pro file is modified to make sure linking of the library succeeds without duplicate symbol errors, which qmake doesn't encounter due to magical exclusion of cpp files that are included in other cpp files (presumably for include moc_foo.cpp support) - feature evaluation for Core, Gui, Network now happens in the qtbase/src directory, so that bundled libraries can be conditionally built - for each bundled library there are now two FindWrap scripts: - FindWrapSystemFoo which finds an installed library in the system - FindWrapFoo which either uses the system installed library or the built bundled one depending on a condition - projects that intend to use bundled libraries need to link against WrapFoo::WrapFoo instead of WrapSystemFoo::WrapSystemFoo targets (this is handled by pro2cmake). Unfortunately manually added qt_find_package(WrapFoo) calls might still be needed as is the case for WrapFreetype and others. - a new cmake/QtFindWrapHelper.cmake file is added that provides a macro to simplify creation of WrapFoo targets that link against a bundled or system library. The implementation is fairly ugly due to CMake macro constraints, but it was deemed better than copy-pasting a bunch of almost identical code across all FindWrapFoo.cmake files. - a qtzlib header-only module is now created when using bundled zlib, to provide public syncqt created headers for consumers that need them. These are projects that have 'QT_PRIVATE += zlib-private' in their .pro files (e.g. qtimageformats, qtlocation, qt3d, etc.) This is unfortunately needed due to QtNetwork using zlib types in its private C++ API. The change includes support for building the following bundled libraries: - zlib - libpng - libjpeg - Freetype - Harfbuzz-ng - PCRE2 The following 3rd party libraries are still using an old implementation within the CMake build system, and should be migrated to the new one in the near future: - double-conversion - Old harfbuzz The are a few libraries that are not yet ported: - system-sqlite - systemxcb - maybe others Among other things, this change allows building qtbase on Windows without requiring vcpkg. Task-number: QTBUG-82167 Change-Id: I35ecea0d832f66c1943c82e618de4a51440971a5 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
2020-02-14 13:53:28 +00:00
set(${_unique_prefix}_qt_package_success_message
"Using Qt bundled ${_qfwrap_${_unique_prefix}_FRIENDLY_PACKAGE_NAME}.")
set(${_unique_prefix}_qt_package_type "bundled")
else()
set(${_unique_prefix}_qt_package_name_to_use
"${_qfwrap_${_unique_prefix}_SYSTEM_PACKAGE_NAME}")
set(${_unique_prefix}_qt_package_target_to_use
"${_qfwrap_${_unique_prefix}_SYSTEM_PACKAGE_TARGET}")
set(${_unique_prefix}_qt_package_success_message
"Using system ${_qfwrap_${_unique_prefix}_FRIENDLY_PACKAGE_NAME}.")
set(${_unique_prefix}_qt_package_type "system")
endif()
if(NOT TARGET "${${_unique_prefix}_qt_package_target_to_use}")
find_package("${${_unique_prefix}_qt_package_name_to_use}")
endif()
if(TARGET "${${_unique_prefix}_qt_package_target_to_use}")
set(${_qfwrap_${_unique_prefix}_WRAP_PACKAGE_FOUND_VAR_NAME} ON)
message(STATUS "${${_unique_prefix}_qt_package_success_message}")
add_library("${_qfwrap_${_unique_prefix}_WRAP_PACKAGE_TARGET}" INTERFACE IMPORTED)
target_link_libraries("${_qfwrap_${_unique_prefix}_WRAP_PACKAGE_TARGET}"
INTERFACE
${${_unique_prefix}_qt_package_target_to_use})
set_target_properties("${_qfwrap_${_unique_prefix}_WRAP_PACKAGE_TARGET}" PROPERTIES
INTERFACE_QT_3RD_PARTY_PACKAGE_TYPE
"${${_unique_prefix}_qt_package_type}")
elseif(${_unique_prefix}_qt_package_type STREQUAL "bundled")
CMake: Handle conditions in third party find modules correctly Previously the FindWrap modules checked for hardcoded features when deciding whether to use a bundled library or not. This proved not to work correctly because features were not available when the find modules were processed. Introduce a new CMake API call that needs to be manually called after an add_subdirectory call which declares a bundled library. The call will check for the existence of the bundled target, and will then set a cache variable QT_USE_BUNDLED_Bundled<TargetName>. The same variable is written into a FindWrapFooConfigExtra.cmake file which will be loaded by the appropriate FindWrap module. The module can that use that variable to decided whether to link against the bundled library or the system library. Change-Id: I75e9a4f4e14d88d4490916a79ad12f1ce57891e0 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2020-03-05 12:15:34 +00:00
message(FATAL_ERROR "Can't find ${${_unique_prefix}_qt_package_target_to_use}.")
CMake: Allow building bundled 3rd party libraries in qtbase A few things are needed to accomplish that: - the python scripts do not ignore certain system_foo features anymore (it is a hardcoded list for now just to be safe) - configurejson2cmake now outputs qt_find_package(WrapSystemFoo) calls for bundled libraries (see below) - the harfbuzz .pro file is modified to accommodate pro2cmake not being able to correctly parse some conditional scopes - the freetype .pro file is modified to make sure linking of the library succeeds without duplicate symbol errors, which qmake doesn't encounter due to magical exclusion of cpp files that are included in other cpp files (presumably for include moc_foo.cpp support) - feature evaluation for Core, Gui, Network now happens in the qtbase/src directory, so that bundled libraries can be conditionally built - for each bundled library there are now two FindWrap scripts: - FindWrapSystemFoo which finds an installed library in the system - FindWrapFoo which either uses the system installed library or the built bundled one depending on a condition - projects that intend to use bundled libraries need to link against WrapFoo::WrapFoo instead of WrapSystemFoo::WrapSystemFoo targets (this is handled by pro2cmake). Unfortunately manually added qt_find_package(WrapFoo) calls might still be needed as is the case for WrapFreetype and others. - a new cmake/QtFindWrapHelper.cmake file is added that provides a macro to simplify creation of WrapFoo targets that link against a bundled or system library. The implementation is fairly ugly due to CMake macro constraints, but it was deemed better than copy-pasting a bunch of almost identical code across all FindWrapFoo.cmake files. - a qtzlib header-only module is now created when using bundled zlib, to provide public syncqt created headers for consumers that need them. These are projects that have 'QT_PRIVATE += zlib-private' in their .pro files (e.g. qtimageformats, qtlocation, qt3d, etc.) This is unfortunately needed due to QtNetwork using zlib types in its private C++ API. The change includes support for building the following bundled libraries: - zlib - libpng - libjpeg - Freetype - Harfbuzz-ng - PCRE2 The following 3rd party libraries are still using an old implementation within the CMake build system, and should be migrated to the new one in the near future: - double-conversion - Old harfbuzz The are a few libraries that are not yet ported: - system-sqlite - systemxcb - maybe others Among other things, this change allows building qtbase on Windows without requiring vcpkg. Task-number: QTBUG-82167 Change-Id: I35ecea0d832f66c1943c82e618de4a51440971a5 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
2020-02-14 13:53:28 +00:00
endif()
endmacro()
Reference in New Issue Copy Permalink