Building QET is dominated by re-parsing Qt's headers. A 214-line source
file expands to roughly 198,000 preprocessed lines, and compiling one
translation unit costs ~4.1 s, of which only ~0.35 s is optimisation --
switching -O3 to -O0 saves just 8%, so the usual "build Debug for faster
compiles" advice does not help here. A precompiled header caches the
parsed header state, which is the part that actually costs.
Measured on a 24-thread Xeon E5-2650 v4 with Qt 5.15.18 and GCC 15.2,
same build tree, only the option differing:
compile one translation unit 4.12 s -> 1.21 s
edit one .cpp -> linked binary 5.22 s -> 1.65 s
Deliberately OFF by default. A PCH satisfies includes that a source file
neglected to make for itself, so code written with it enabled can fail to
compile for everyone else. Leaving the default off keeps CI and
contributors on the strict behaviour; only developers who opt in trade
that away for the speed.
Two details in the implementation are load-bearing:
- The generator expressions are not decoration. This target also compiles
the 18 C files of the bundled LZMA decoder, and an unguarded header list
applies to every language in the target, so the Qt headers would be fed
to the C compiler and fail with "unknown type name 'namespace'".
$<ANGLE-R> is needed because a literal '>' would end the generator
expression.
- target_precompile_headers() requires CMake 3.16 while the project still
declares a 3.5 minimum, so the block warns and skips rather than raising
the project-wide requirement for an opt-in developer feature.
Verified both ways: with the option off no PCH artefacts are generated and
the build is byte-for-byte the previous behaviour; with it on, all 18 C
files still compile, the generated PCH is C++-only (cmake_pch.hxx, with no
cmake_pch.h), the C compile commands carry no PCH, and the resulting
binary runs.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
CMake's bundled FindSQLite3 module only creates the SQLite3::SQLite3
target since CMake 4.3; earlier versions (still used by most current
Linux distros) only provide SQLite::SQLite3, which CMake >= 4.3 now
flags as deprecated.
Add the missing alias ourselves right after find_package(SQLite3)
when it isn't already provided, so the project can link against the
modern SQLite3::SQLite3 name on every supported CMake version without
triggering the deprecation warning on newer ones.
Listing GuiPrivate unconditionally in QET_COMPONENTS breaks the whole
Qt5 configure: find_package(Qt5 COMPONENTS GuiPrivate) looks for a
Qt5GuiPrivateConfig.cmake that has never existed - Qt5 creates the
Qt5::GuiPrivate target implicitly together with Gui. Only Qt6 requires
(and provides) the explicit component.
Move the request into a QT_VERSION_MAJOR-guarded find_package after the
main one, both for the application and for tests/catch (whose targets
link Qt::GuiPrivate via QET_PRIVATE_LIBRARIES). Fixes the msys2/Qt5
Windows CI configure failure:
"Could not find a package configuration file provided by Qt5GuiPrivate".
Verified: Qt 6.11 configure passes and the Qt6::GuiPrivate target is
created (the private-module warning now fires from the guarded call).
The Qt5 path simply no longer requests the component, restoring the
pre-existing implicit behaviour.
The default build ran both lupdate (qt5_create_translation, which
rewrites the tracked .ts files in the source tree) and lrelease
(qt5_add_translation, which reads the same .ts files). Under high
parallelism lrelease could read a .ts while lupdate was rewriting it,
failing the build with "Premature end of document"; every build also
modified tracked files as a side effect, and each .qm was generated
twice (once into the build dir, once into lang/).
Keep only lrelease in the default build and move lupdate behind an
explicit developer target (cmake --build . --target update_translations).
The target scans sources/ instead of the whole source tree, which also
stops lupdate from parsing unrelated third-party .js files.
The BUILD_WITH_KF5 option was checked with DEFINED, so passing -DBUILD_WITH_KF5=OFF still entered the KF5 setup path.
Skip the KF5 setup when disabled and provide small Qt-only replacements for the KDE color widgets used by .ui files in that build mode.
Assisted-by: pi coding agent / Mika (OpenAI GPT-5.5)
- Resolve cmake/qet_compilation_vars.cmake conflict: keep both upstream's
cli_export.cpp/h and pdf_links.cpp/h and the EDZ source additions.
- 10-position grid alignment: pin_y values are multiples of 10 so terminals
snap cleanly to QET's default grid. group_gap raised to 10 (one full slot).
- Named connector groups get a header label (group name) placed in the gap
above the first pin, so the electrician sees block names (XDI, XPOW, …)
without reading individual terminal designations.
- Device-tag dynamic_text now uses 9pt LABEL_FONT and y = min_y - 9 so it
clears the element body and is legible at normal zoom.
- Add EPLAN Data Portal Terms of Use disclaimer to sources/import/edz/README.md.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Replaces the QProcess->7z shim with the public-domain LZMA SDK (23.01) 7-Zip
reader, vendored under sources/import/edz/lzma/ (decode-only subset). New
edzsevenzip.cpp wraps SzArEx_Open/SzArEx_Extract and writes entries via Qt, so
EdzArchive no longer needs an external 7-Zip at runtime. Enables the C language
in CMake for the vendored sources.
Verified: the bundled decoder extracts all three ifm sample .edz and the
generated elements still match the Python oracle exactly (byte-correct decode),
with no 7z on the path.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The .desktop, MIME package, and appdata install rules are
freedesktop.org conventions and only apply on Linux. Wrapping
them in if(UNIX AND NOT APPLE) prevents a configure failure on
macOS and Windows where QET_APPDATA_PATH and QET_MIME_PACKAGE_PATH
are not defined.
Also replace the hardcoded share/mime/packages path with
${QET_MIME_PACKAGE_PATH} for consistency with
paths_compilation_installation.cmake.
No change to Linux build behaviour.
Those desktop MIME types were needed only with KDE up to 3.x, as it
used to have its own desktop-based MIME type system. KDE 3 is EOL for
many years now, and there are already XDG MIME types.
These files are the bare XML definitions, and they are automatically
generated by update-mime-database (part of shared-mime-info) on update
(e.g. by distro hooks) or manually. Keeping them in the sources, and
installing them, is definitely not correct, as qelectrotech.xml is
their canonical definition.
Hence, drop them from the sources, together with references to them.
ispyisail