Qt5 before 5.12 has to use qcollectiongenerator
instead of qhelpgenerator, which also exists but creates an error.
if qcollectiongenerator prioritize it.
Use "${QT}::qhelpgenerator" instead of
"find_program(QTCOLLGEN NAMES qhelpgenerator ....)"
Add CACHE Variable QTFIXEDVERSION allowing to force Qt5 or Qt6
if both are installed.
XCA now supports both, Qt6 and Qt5 down to Qt-5.2
Use CMAKE_PREFIX_PATH to point to the QT dompiler directory like
$ cmake -B build -DCMAKE_PREFIX_PATH=$HOME/6.3.1/gcc_64
When I followed the step-by-step documentation for the first time, I was confused at first by the New Certificate button being greyed out.
This commit adds a section which explains creating the database before creating a certificate.
Also remove stamp files and simplify CMake rules:
- Name all generated files in OUTPUT
- Drop BYPRODUCT, which is not necessary now.
- Let the target depend on all OUTPPUTs of the command.
The long list of translations and html documentation
pages is now auto-generated by the cmake files,
which know the translations and html files. (DRY)
TODO: Windows SQL drivers for mysql and psql
- Always build html documentation if sphinx-build is available.
to be installable during install
- Collect "${D}/qthelp/xca.qhc" "${D}/qthelp/xca.qch" in QTHELP_IDX
and use this instead.
- On linux also install the qthelp in an html subdirectory like WIN32
- Don't instanciate QHelpEngine if no help available.
Rename XCA_SPECIAL to XCA_ARGUMENTS, which is less generic.
and change %1_OPTIONS to XCA_%1_OPTIONS to prefix all
XCA related environment variables with "XCA_".
Why?
- QT will switch from qmake to cmake sooner or later.
- autotools are good for unix-ish systems, cmake also for
macOS and Xcode as well as Windows and VS-code
- Cross compiling the windows-binaries on linux
is not very helpful to attract windows-centric
developers.
Also drop qmake's xca.pro
Generate man-page and sphinx sources of commandline arguments
during build by executing xca (xcadoc.cpp).
Generating Version-patchlevel and git hash is now also
OS independent.
git.release.something ->
Create any git release with a tag to test package (debian/rpm) build
git.release -> Create required changes and tags for the next release
git.publish -> Finalize the release (github release)
gen-binary-hash / binary-hashes.json -> keep track of release hashes
For an official release XCA_VERSION == PACKAGE_VERSION.
For any additional commit, XCA_VERSION's path-level is increased.
PACKAGE_VERSION cannot be modified after initially set.
Change any occurance of PACKAGE_VERSION by XCA_VERSION
