| Age | Commit message (Collapse) | Author |
|---|
|
Summary:
Allows to check if a module is available on the system and sets it as a
runtime dependency.
This is useful for projects so that they can specify their qml dependencies
easily and packagers and developers get to see what's missing by looking
at the cmake output.
Reviewers: #build_system, #frameworks, sitter
Reviewed By: sitter
Subscribers: dfaure, aacid
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D7094
|
|
Currently the test still passed even if one of the check_translations()
calls would fail.
The reason is that check_translations() is a function which has its own
scope, so if it sets "failed" the upper level doesn't see it.
Use the PARENT_SCOPE option when setting the variable to properly
propagate the value to the upper level.
Differential Revision: https://phabricator.kde.org/D6701
|
|
|
|
Summary:
Enables generation of QCH files during a normal build,
for documenting the public API of a library.
These macros are especially done with release builds in mind,
so distributed packages (like from Linux distributions) can
include QCH files matching the version of the library and will be
also automatically updated on new versions of the libary.
Next to that these macros also support linking between different
QCH files, so a subclass from another library for which there also
is a QCH file installed will be linked to the entry in that other
QCH file.
This inter-QCH linking is especially useful for libraries extending Qt,
where many of the used types are from Qt libraries. The macros
come with the needed information for Qt libraries prepared, so the
used Qt libraries just need to be listed in the LINK_QCHS argument
by target names, like Qt5Core_QCH or Qt5Widgets_QCH.
This should be a nice supplement to online services like api.kde.org,
like Qt's own QCH files are to doc.qt.io,
While QCH files from an abstract POV could be seen similar to code
libraries, being components with links to lookup symbols/entries in
other QCH files, so the rules and code should be done with similar
concepts, currently CMake's target system seems bound to executable
code creation. So things like "file(EXPORT ...)" could sadly not be
reused, as custom targets are not supported with that.
Thus a custom macro had to be created for now. Also could I not find
a way to use namespaces like KF5::, for more consistent target naming.
The patch also adds two variables to KDEInstallDirs.cmake for
controlling where the QCH (and respective doxygen tag files) are
installed. The QTQCHDIR variant allows to install QCH files for
Qt-extending libraries into the same folder where Qt's own QCH
files are, so Qt Assistant & other QCH viewer pick up them automatically
to add them to the default help file collection.
The QCHDIR variant would provide a neutral, but central installation
location. Neutral, as it never "pollutes" the Qt system dirs with files
possibly unrelated to Qt-based development (e.g. when simply using qthelp
tools for documentation), and central, to help with finding available QCH
files for manually adding/loading them into a viewer, given there is no
official way currently to register the availability of QCH files on
installing.
Open questions:
a) target system for exporting/importing done in a sane way?
Better name pattern for the QCH targets than xxx_QCH
(see the targets created for Qt, like Qt5Core_QCH)?
b) sharing metadata with kapidox
Initially I placed these macros into the kapidox module, as this seems the
logic place. And would match what kdoctools does for user manuals.
Just, that would create a build dependency on kapidox which complicates usage
a little. Having these macros in ECM delivers them with no extra effort
needed.
The data in metainfo.yaml is partially duplicated with the data feed into
the macros. How to deduplicate that is still open. Especially with the need
to not depend on external data sources like identify.kde.org.
Issues:
* doxygen versions before 1.8.13 are broken and miss to include some files
with generated QCH (https://bugzilla.gnome.org/show_bug.cgi?id=773693)
* Qt Assistant often only built with QTextBrowser, while doxygen uses lots
of HTML5 (incl. hardcoded JavaScript)
(https://bugzilla.gnome.org/show_bug.cgi?id=773715),
needs e.g. distributions to use QtWebKit to work, upcoming Qt versions
might soon also have QtWebEngine based help viewer
(https://codereview.qt-project.org/#/c/111559/)
* inter-QCH links do not work in KDevelop currently
(see https://bugs.kde.org/show_bug.cgi?id=372747) if installed as
separate QCH files
More details/background info at
https://frinring.wordpress.com/2016/09/27/adding-api-dox-generation-to-the-build-by-cmake-macros/
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D2854
|
|
when checking whether there were new sources added (on Windows and Mac),
check whether the variable is empty as list, instead of failing because
of a cmake syntax error
|
|
hopefully the dummy executable will be where expected (on Windows)
|
|
include the ECMMarkNonGuiExecutable module, so the
ecm_mark_nongui_executable can be used
|
|
use ecm_mark_nongui_executable to mark the dummy executable as non-gui,
so its linking works
|
|
Set KDE_INSTALL_USE_QT_SYS_PATHS explicitely to FALSE, to avoid
it defaulting to TRUE if Qt is also installed to the /usr prefix
|
|
Summary: Otherwise it doesn't work when falling back to the project name.
Test Plan: Ran the test locally with and without .git directory
Reviewers: #frameworks, joselema, sitter
Reviewed By: sitter
Subscribers: #build_system
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D5741
|
|
Summary: It turns out it's more complex than it looks, it's always better to have tests.
Reviewers: sitter, aacid
Reviewed By: sitter
Subscribers: #frameworks, #build_system
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D5352
|
|
With some combination of PyQt/compiler this breaks the build of
kcoreaddons.
This reverts commit 2e20aeab6e86670a66ff99a7b79120c4004b4d22.
|
|
|
|
|
|
Don't export API which has visibility "hidden".
Visibility attributes on variables are ignored, but call the generic
method anyway.
Remove checks for macros which obscure the attributes. Processing the
attribute directly means that is not needed.
|
|
|
|
|
|
|
|
|
|
Don't prepend a namespace to it as we do otherwise with enum/flags.
|
|
Don't process the same function name twice.
|
|
It is not appropriate to decorate each forward declaration with the SIP
attribute /External/. That is only needed for forward declarations of
types which are defined in a different module.
Local forward declarations can be omitted from the sip code. In sip
code, a forward declaration followed later by a full class definition is
an error.
Omit forward declarations unless they are decorated with the external
attribute. Introduce a rules database for consumers to decorate them
with the attribute as required.
|
|
Custom rules should be able to deal with lists in these cases. This is
already the case for function parameters.
|
|
|
|
Currently this is rather simple, allowing only matching typedefs by
name. If we need more later, we can extend the interface. This will
make it possible to add bindings for the K18n framework.
|
|
|
|
The Q_DECLARE_TR_FUNCTIONS macro contains a `public:` access specifier,
but the sip_generator just pastes the entire macro name. Adjust the
generator to extract the correct access specifier.
|
|
|
|
Increase test coverage regarding transformations.
|
|
|
|
|
|
|
|
This works with 3.2, and I don't remember why I made it 3.3.
|
|
Don't rely on transitive inclusion
|
|
It should be optional.
|
|
This can be used by KF5 libraries to generate python 2 and 3 bindings.
|
|
REVIEW: 128780
|
|
Needed for many unit tests to add them to APK files.
REVIEW: 128175
|
|
REVIEW: 126711
|
|
templates are very useful as teaching tool in order to make
a minimal application that uses a certain framework.
templates in the KAppTemplate repository will always get forgotten
(plus kapptemplate is not really necessary as they work in kdevelop as well)
An ideal situation would be frameworks having templates in their own repos
with templates of barebone apps using the main framework features.
In order to do that, the cmake stuff needed in order to correctly install
a template needs to be ported to a place avaiable to all frameworks
REVIEW:126185
|
|
|
|
Because the old implementation (accidentally) worked when you put the
ecm_create_qm_loader call in a different CMakeLists.txt file to the
target the file was added to, some projects did this.
This won't work with build-time-generated files, though, like moc files.
So we (ab)use QTimer events to make the loading happen on the main
thread.
BUG: 346188
REVIEW: 126000
|
|
It should now be easier to read, and more featureful. Among other
tweaks, we now print a summary of dependencies and build options, and
the documentation is generated with more sensible breadcrumbs and
builds properly with Sphinx 1.3.
REVIEW: 126075
|
|
Multiple ecm_create_qm_loader() with different catalog names would
overwrite each other's generated files, causing the wrong catalog to be
loaded at runtime for some targets.
This puts the catalog name into the generated filename. Since the
catalog name is the only difference between the generated files, this is
sufficient to fix the runtime behaviour.
REVIEW: 125999
|
|
This is based on commit 6745bd7e4796560959bb67e33b7c7f86f96a5a94 (and
the subsequent fix-up commits).
|
|
This broke the build for projects which used ecm_create_qm_loader in
unusual ways. A better approach is coming, but won't be in e-c-m 5.16.
This reverts commit 009c480413910e8c1a18f4d1420f4a517ea606e6.
CCBUG: 346188
CCMAIL: release-team@kde.org
CCMAIL: kde-buildsystem@kde.org
|
|
This commit is dependent on 009c480413910e8c1a18f4d1420f4a517ea606e6,
which is the primary commit to be reverted.
This reverts commit 634a0a2d3d7ba1bec2bae846acf0faf6184f4c71.
|
|
This commit is dependent on 009c480413910e8c1a18f4d1420f4a517ea606e6,
which is the primary commit to be reverted.
This reverts commit 0496f8ae020c497b5f65234063150781d023f8ba.
|
|
This commit is dependent on 009c480413910e8c1a18f4d1420f4a517ea606e6,
which is the primary commit to be reverted.
This reverts commit 39484722101730d4f1a4bccbc5467c0eb2cc0f6f.
|
|
The V1 syntax of ecm_install_icons searched for icons by globbing files
with a particular naming pattern. If there were no such icons, this used
to do nothing, but silently. Commit fb7b8eea7d accidentally made this an
error. More sensible would be to make it a warning.
BUG: 354610
REVIEW: 125931
|
