QMAKE_PRL_LIBS_FOR_CMAKE can contain "-F/foo/bar" entries which
are search paths for where frameworks should be found.
These should be passed as HINTS to find_library when searching for
frameworks.
Fixes: QTBUG-81369
Change-Id: I4f699800bd49a1f368b6132823e23d08d1fae604
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
When scanning the prl files to set up usage requirements for the Qt libraries
we omitted "-framework Foo" flags. Those were passed as linker flags, but not
as interface libraries. Consequently, the frameworks that are used by Qt
libraries were missing on the link line when building against a statically
built Qt.
Fix this issue by scanning the dependencies for "-framework Foo" just like we
do with "-lfoo" flags.
Fixes: QTBUG-80855
Change-Id: Ie7804304141c86207d143a6e1005e78bdc099113
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Reviewed-by: Kyle Edwards <kyle.edwards@kitware.com>
After appropriate link flags are determined, they are added to the
INTERFACE_LINK_OPTIONS property. Unfortunately this property was added
in 3.13, and thus static builds on Windows for instance failed with
missing symbols due to missing system libraries on the link command
line, when the CMake version was lower.
When detecting a lower version, add the flags instead to
INTERFACE_LINK_LIBRARIES, which is a property that is available in
older CMake versions. To do this we have to strip the SHELL: prefix,
which means that the added link flags might get deduplicated, and thus
it can happen that the linking phase might still fail.
Nevertheless, on Windows this improves the situation when using an older
CMake version.
Amends 44602224bf
Task-number: QTBUG-38913
Change-Id: Ib710b8ea691d4a9281dcd5f5b9700b11df0a5c10
Reviewed-by: Kyle Edwards <kyle.edwards@kitware.com>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
When Qt was configured with -libdir different from "lib", one could not
build with CMake whenever a static lib was pulled in (e.g. uitools).
Do not hard-code "/lib" but use the correct variable also for static
libraries.
Fixes: QTBUG-76255
Change-Id: I28c6861752e29e461247628d2b1f8a9ec32f0790
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Fabian Vogt <fabian@ritter-vogt.de>
It is forbidden to set upper case named properties on CMake
interface libraries which do not start with the "INTERFACE_"
prefix. Rename QT_PLUGIN_TYPES to INTERFACE_QT_PLUGIN_TYPES.
There does not seem to be any usage of the property, so it's just for
informational purposes, so it's a one line change.
Fixes: QTBUG-77754
Change-Id: I3621f2b6188c3c72c4c2446f93ba1e078b755f72
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
This commit adds transitive dependencies to the plugins, so that a
sane set of default plugins get auto-imported when linking against a
module. It also provides a new function, qt5_import_plugins(), which
allows you to override the set of plugins that get imported. The decision
of whether or not to import a specific plugin is based on several custom
target properties and a very clever generator expression.
Note that this change only imports plugins on static Qt builds. It
does nothing on shared Qt builds, as the shared libraries already have
their own plugin import mechanism.
[ChangeLog][CMake] Added ability to auto-import non-qml plugins on
CMake builds
Task-number: QTBUG-38913
Task-number: QTBUG-76562
Change-Id: I2d6c8908b521cf6ba1ebbbc33a87cb7ddd9935cf
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
When doing plugin auto-importing as part of a Qt static build, it can
happen that the same module FooConfig.cmake file is loaded twice.
Make sure not to create the same target twice if it was already
created previously.
Task-number: QTBUG-38913
Change-Id: I734c83ff3c0bb9e3ee9bff37971209c57abaa2b9
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
In a CMake regex, you need two backslashes to escape a character. The
.in file therefore needs four backslashes ...
This amends ba4fdd99ff
Fixes: QTBUG-76698
Change-Id: Ic757354ba596bf020c3ee5e90ee6d2d0fe3ba352
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This change will create Config.cmake files for internal modules like
AccessibilitySupport when doing static builds. They need to be
find_package()'ed and linked in when linking in certain qt plugins.
Task-number: QTBUG-38913
Task-number: QTBUG-76562
Change-Id: Ia2e446025c87df48f20bb65cfd9da6c6a4354bb1
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
When adding the static dependencies for a module, they should be
added to the debug|release configuration as appropriate, otherwise
it ends up adding the debug version of the libraries to the release
configuration as well as the release version of the libraries.
Implementation wise, that means we have to use generator expressions
of the form $<$<CONFIG:Configuration>:${dependencies}>, because
INTERFACE_LINK_LIBRARIES does not have a
INTERFACE_LINK_LIBRARIES_<CONFIG> equivalent that can be set per
configuration.
Note that the condition part of the generator expression can not
explicitly check for Debug or for Release, because a user can
configure their application without specifying CMAKE_BUILD_TYPE,
which means that both Debug and Relase conditions would fail.
So the actual condition has to be isDebug or isNotDebug.
The same approach is used for INTERFACE_LINK_OPTIONS.
For debug_and_release builds we use the isDebug and isNotDebug
conditions for the generator expressions.
For singular builds (only release or only debug), we set the
generator expression condition to "1" aka always true.
This means that the Qt libraries and link options will always be used
regardless of the configuration with which the CMake application
is configured with.
Fixes: QTBUG-76337
Task-number: QTBUG-38913
Change-Id: I5369d8ba083359a4a92253dbd1dabe9d1efa34db
Reviewed-by: Andy Shaw <andy.shaw@qt.io>
The absolute paths of certain static dependencies can have spaces in
them. The _qt5_$${CMAKE_MODULE_NAME}_process_prl_file fails to handle
this, and simply replaces all spaces with semicolons, which obviously
breaks the list of dependencies, and a consuming application fails to
link with a message like:
LINK : fatal error LNK1181: cannot open input file 'C:\Program.obj'
This change partially restores the functionality that was added in
102e1822ff specifically the part
that changes qmake to export an additional variable
QMAKE_PRL_LIBS_FOR_CMAKE. This variable has the same content as
QMAKE_PRL_LIBS except it uses a semicolon as a separator, so that
CMake can correctly parse the separate lib entries.
This is much cleaner than trying to parse the original QMAKE_PRL_LIBS
variable with a complicated regular expression.
Amends eda28621f6.
Task-number: QTBUG-38913
Change-Id: I1d18fb779606505bc92320d8ce13232c7022e212
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
This change is used to generalize a template docker-compose file for all
modules. Ideally, the leaf module only need to keep a docker compose
file for all platforms (docker-compose.yml).
NOTE:
The version of docker-compose file downgrades from 3.4 to 2.1 because
the 'extends' keyword is not supported in Compose version 3.x.
Change-Id: I2e36fd9236eda86cb5fcf940d787ccefe9200696
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io>
Done to fix broken CMake WebAssembly support, where CMAKE_CXX_STANDARD_LIBRARIES
appear to be empty. The regression was introduced by
ba4fdd99ff.
This fixes the following CMake error on find_package(Qt ...):
string sub-command REGEX, mode REPLACE needs at least 6 arguments total to command.
Fixes: QTBUG-73475
Fixes: QTBUG-76244
Change-Id: Ieebe8cd1d49bb302dc37d8f118cc0b9376d6cdd7
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Do not call find_library() on libs that are part of CMAKE_CXX_STANDARD_LIBRARIES:
At CMake call time they might not be found.
Fixes: QTBUG-73475
Change-Id: I350b3280744883e82d83c46e70f6a7cfc8aeed2e
Reviewed-by: Andy Shaw <andy.shaw@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This is a follow-up to f5850cb0da, which
did not take into account some special-casing for macOS framework build,
thus causing CMake to look for QtFoo.framework instead of Foo.framework.
Change-Id: I261b14e75fde66fb57486bde43fc936f796a6f96
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Kevin Funk <kevin.funk@kdab.com>
Do remove quotes around libraries before trying to parse them.
This patch is a follow-up to eda28621f6, and fixes
an issue on Windows where e.g. Qt5AxServer.prl contains entries
like
"-lole32"
Fixes: QTBUG-73475
Change-Id: I3d1353de618328a0d44bacd4dbd6aba8fc66b1b7
Reviewed-by: Kyle Edwards <kyle.edwards@kitware.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This patch is a follow-up to eda28621f6.
It adds a translation of the $$[QT_INSTALL_LIBS] variable into
a path that CMake understands.
Without this, CMake finds the system libraries if there are any
instead.
It also handles the case where the .prl file contains absolute paths to
libraries, as it happens for instance on Debian systems.
Task-number: QTBUG-38913
Change-Id: If68373efee22bc00172e8fead3e2c12ea440787f
Reviewed-by: Kyle Edwards <kyle.edwards@kitware.com>
Reviewed-by: Kevin Funk <kevin.funk@kdab.com>
rather than reproducing vcvarsall.bat's functionality as hard-wired code
in the nmake generator, just invoke the actual script from
toolchain.prf. this is much easier, more future proof, and - critically
- makes the detected variables available to configure's new library &
header search facilities.
[ChangeLog][Important Behavior Changes][qmake][WinRT] Cross-builds will
now ignore pre-set values of %INCLUDE% and %LIB% when building target
executables. If necessary, use configure's -I and -L switches when
building Qt, and pass QMAKE_INCDIR and QMAKE_LIBDIR on qmake's command
line when building own projects.
Change-Id: I36f53e8880d6523f3f6f7a44d40d87d04bd06854
Reviewed-by: Thomas Miller <thomaslmiller91@gmail.com>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
This change reinstates functionality that was removed in
commit 102e1822ff. However, it
differs from the original implementation in several ways:
* It uses the QMAKE_PRL_LIBS variable, replacing whitespace with
semicolons, rather than using a dedicated QMAKE_PRL_LIBS_FOR_CMAKE
variable.
* More importantly, it parses the -L and -l flags and uses CMake's
find_library() command to look for the libraries in the specified
search paths, and then converts them to absolute paths. This is the
same approach that CMake's own FindPkgConfig module uses to find
libraries specified in this form. Any other flags not of the form
-L or -l (for instance, -s flags passed to Emscripten) are added to
the new INTERFACE_LINK_OPTIONS target property if the CMake version
is 3.13 or newer.
The original implementation of this functionality was removed because
of the lack of absolute library paths. At the time, it was believed
that qmake would have to be modified to do its own equivalent of
find_library() to get the absolute paths to the libraries. However,
the approach taken by FindPkgConfig has proven robust enough to be
used here, allowing CMake to find the absolute paths to the libraries
without having to modify qmake.
[ChangeLog][CMake] Added support for automatic linking of transitive
dependencies in static builds
Fixes: QTBUG-38913
Change-Id: I7d9cdb0d339c6ef697b04099d129481c770fc0fc
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Xcode 10 ships version 921.0.1 of cctools, which otool is part of. The
defaults have changed in that version to no longer print verbosely
(symbolically), which we relied on. We now request it explicitly.
Change-Id: Ifbe0c97462b9f78cf128c820847eff9c72f17065
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Tim Blechmann <tim@klingt.org>
... for debugging purposes.
this needs to work in every configure run even though the options
(currently) come from qtbase's global scope. this is accomplished by
automatically injecting the test type dependencies declared in the
'builtins' scope (where they generally make no sense whatsoever, because
there are no tests there) into other scopes (the first one that has a
test of the particular type, specifically). we do that *after* the
scope's own test type deps, so it can do its custom stuff first (it can
explicitly activate the required features if it depends on some global
stuff).
Change-Id: I67317da1b55804d39458bdbcf13d39a3e57a13bf
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Add properties enabled_features and disabled_features the respective
library targets.
This makes it possible to query the enabled classes in dependent libraries
(for example, Qt for Python).
Add a test verifying whether the Open GL configuration is reflected
correctly in the feature properties to the existing test_opengl_lib
autotest.
Change-Id: I645c947073dbb36da3be81de6bc62ee0ba1e73d6
Reviewed-by: Kevin Funk <kevin.funk@kdab.com>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
This removes the following functions from Qt5CoreMacros:
- qt5_use_modules(...)
Task-number: QTBUG-63519
Change-Id: I59769060a3a93686bf319b558c0ede55755fdb70
Reviewed-by: David Faure <david.faure@kdab.com>
especially during debugging, it is often necessary to re-run only one
(or a few) tests, where -recheck-all would be wasteful.
Task-number: QTBUG-64059
Change-Id: I9410894dec4289ff832d7f75e04f9b60fe76c57c
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Amends cab060631
Task-number: QTBUG-62995
Change-Id: I374153ec34abad0585d2bcab0f699b42600be6ef
Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@qt.io>
Before testserver becomes a stable feature, let's keep testserver.prf in
"mkspecs/features/unsupported". The test server's shared files will be
stored in "mkspecs/features/data/testserver".
Because the path of testserver has been changed, all the tests relying
on the docker servers should be updated as well.
Change-Id: Id2494d2b58ee2a9522d99ae61c6236021506b876
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
So far this only covered the QT_xxx_LIB define, but not any other defines
a module might export (such as QT_NO_QML_DEBUGGER which hasn't been ported
to the new configure system yet).
Change-Id: I8aae2354fed77a6f0e527ad8d63d25654bb067d0
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Kevin Funk <kevin.funk@kdab.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
... and rename those determined by toolchain.prf to QMAKE_* (this was
already the case for the newly introduced msvc and icc variables).
this restores the ability for user projects to query the toolchain qt
itself was built with, which is necessary for compatibility checks.
in fact, we may do such validation in toolchain.prf itself at a later
point.
Change-Id: I35f4c393c5e4e0fe987c0844714b7a8f8687c24e
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
this actually just makes the code more straight-forward.
amends f8607045c.
Task-number: QTBUG-60936
Change-Id: Iaa05b474206cf29352f9bba516936ff30b90a778
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
This change restores usability of Qt with older versions of CMake which
do not provide a language feature used in the implementation of the new
Qt5::<ModuleName>Private targets.
Task-number: QTBUG-60229
Change-Id: I6a6a1b09be3edca200692250bb8f0d7f6a1b8f7a
Reviewed-by: Stephen Kelly <steveire@gmail.com>
The configure-time detection (cxx11default) isn't enough if the compiler
can be changed. This is especially necessary if Qt is compiled with a
compiler that defaults to >= C++11 (e.g., GCC 6) and then the user
selects a compiler another compiler (e.g., Clang) via -spec option. In
that case, we'd miss adding the -std=c++11 or -std=gnu++11 option to the
command-line, causing the compilation to fail.
As a nice side-effect, even moc without moc_predefs.h will now get the
__cplusplus setting.
Task-number: QTBUG-58321
Change-Id: I74966ed02f674a7295f8fffd14a8be35da9640e1
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
currently mostly for debugging purposes (especially with -verbose).
Change-Id: I8af32c61df0b19861aa79bc4bbdd3f6095dbe9b7
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
also actually deletes qfeatures.txt, which was already claimed by
a668c6a6, but not actually done.
Task-number: QTBUG-58411
Change-Id: I686760632fee7c10b01bd2e83f2481b01bc2b774
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
the options may need to take effect before the regular test processing
commences (which is actually going to be the case in the next commit).
the indirection via the callback only obfuscated the code anyway.
Change-Id: I5307b0be15cf4cc2c2db391ce5b5a93f81076b5c
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Make it depend on the corresponding Private target of each
dependency. This way, user code can write
find_package(Qt5Gui REQUIRED)
add_executable(hello hello.cpp)
target_link_libraries(hello Qt5::GuiPrivate)
and get the private include directories for both Qt5Core and Qt5Gui.
Don't create the Private target if any of the private include
directories do not exist. This way, if user code uses one of the
targets, CMake will issue an error if the private include directories do
not exist. Unfortunately the error is somewhat cryptic (eg, 'the
"Qt5::CorePrivate" was not found'), but this is still an improvement
over an error at compile time.
This is an improvement on the situation described in QTBUG-37417 using
Modern CMake features.
Change-Id: I034f8216c3ec64d1a3309682456a713cac9bf854
Reviewed-by: Kai Pastor <dg0yt@darc.de>
Reviewed-by: Stephen Kelly <steveire@gmail.com>
this makes it consistent with the determination of the default
include/library paths. this makes sense, as it's possible to switch the
sdk/toolchain after building qt (within reason).
a side effect of this change is that for compilers which emulate other
compilers, both the real and the emulated version are now made
available.
Change-Id: Icfcc672c0d2e3d1b5e622993c366063d70ad327c
Started-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
