| Age | Commit message (Collapse) | Author |
|---|
|
This means removing the find_program() logic, since it was only useful if
we don't want to make CMake spend time finding a compiler; so it was only
useful for building modules that don't need a compiler at all, wallpapers,
icon themes ...etc; so find_program() is only useful when it comes before
the find_package() and enable_language() calls. Thanks to Christophe
Giboudeaux for the explanation. This might make the build time for such
modules a tiny bit longer, but it's worth it to make finding qmake/qtpaths
|
|
Fix finding qmake when executable has no version suffix
|
|
Like is done in the Qt5 qmake code path.
|
|
Some applications look for ECM and need to know Qt paths but
don't need to link to anything. That's the case for icons or
wallpapers.
For these cases, ECMQueryQt will first try to find qmake or
qtpaths before looking for Qt CMake config files.
Also handle cases where project() sets 'LANGUAGE' to 'NONE'.
The CXX language needs to be enabled for find_package to look
for Qt into library dirs.
|
|
Basically copied ECMQueryQmake to ECMQueryQt, added copyright based
on git log, with the BSD 3-clause license; based on the contents of the
README.rst file at the initial commit (commit 96e7fb9969b7 by Rohan Garg) of
ECMQueryQmake, the README file says:
All code is licensed under the BSD 3-Clause license.
Will CC active devs in the MR and email Rohan Garg to confirm.
Then added qtpaths CMake code path, basically you can use query_qt with Qt5
(same syntax, so a drop-in replacement for query_qmake); and Qt6.
The plan is to deprecate ECMQueryQmake in favour of the new module (had to
be done that way as the old module had "qmake" in the name and that could
be a bit confusing).
|
