WIP: CMake build changes
This MR contains a raft of tweaks to the CMake build system, to bring it closer in parity with the autoconf build and/or hopefully make it less quick to fall out of sync. Some of them may need adjustment (hence the WIP), particularly for more-recent changes to the autoconf build. Consider this MR as opening a discussion, as much as proposing changes. All feedback/questions/criticisms welcomed.
So far, the changes represented here include:
Project metadata
- Set version from
RECOLL-VERSION.txt
file
CMake norms/best-practices
- Rename all option vars to RECOLL_* (Note: Takes advantage of CMake's automatic grouping.)
- Add a
FeatureSummary
report at the end of configuration
Dependency discovery
- Find modules are added to the project to facilitate discovery of certain external dependencies
(Note: These live in
src/cmake/
; they could be moved, however somewhere undersrc/
is preferable since that's where the top-levelCMakeLists.txt
lives. Unless we want to add a/CMakeLists.txt
file in the project root, which could then discover the find modules in e.g./cmake/
.)-
src/cmake/FindLibmagic.cmake
- Discover the location of the magic library, ifRECOLL_ENABLE_LIBMAGIC
is true. -
src/cmake/FindFileCommand.cmake
- Discover thefile
binary on thePATH
; only used ifRECOLL_ENABLE_LIBMAGIC
is false. -
src/cmake/FindSystemdPaths.cmake
- Discover the install paths for systemd unit files; only used on Linux, and only ifRECOLL_ENABLE_SYSTEMD
is true.
-
- All of these use the standard overridable cache variables — the path discovered by
FindFileCommand
can be forced by setting the cache variableFileCommand_EXECUTABLE
, the location of the magic library can be overridden withLibmagic_LIBRARY
, etc.
Project configuration
- Support building with Qt5 (by default, in fact;
RECOLL_QT6_BUILD
can be setTRUE
for Qt6. (Note: This may need to be reversed (e.g. default-Qt6), or otherwise revisited, at least in terms of trying to respect a-DQt6_DIR=...
or-DQt5_DIR=...
flag passed tocmake
. But, traditionally autodetection of version-agnostic Qt configurations can break when both are available on the system, as is common in many Linux scenarios. The KDE Project's ECM (Extra CMake Modules) has aQtVersionOption
module with some defaulting support that might be helpful; the currently-implementedQT_MAJOR_VERSION
variable used to select the version is compatible.) - Support building with WebKit if
RECOLL_ENABLE_WEBENGINE
isOFF
(Part of the reason for defaulting to Qt5, it's the only version with QtWebKit support.) - Default
RECOLL_ENABLE_X11MON
toOFF
(even on Linux), as Wayland adoption has increased significantly in recent years (Note: This differs from the autoconf setup; it can be reversed if necessary) - Add
RECOLL_ENABLE_LIBMAGIC
to control use of magic library - Discover
file
command and setFILE_PROG
, if not using libmagic
Build & Install
-
Set
OUTPUT_NAME
forlibrecoll
target, to avoid generatingliblibrecoll.so
. (Note: CMake automatically prependslib
to the output name for library targets. Normally, the target for a library calledlibrecoll
would be calledrecoll
and created usingadd_library(recoll ...)
(thelib
being implicit). But since we already have a target calledrecoll
, theOUTPUT_NAME
property can be used to disconnect the name of the target from the output filename.) -
Split off recoll GUI build into
qtgui/CMakeLists.txt
(Note: Doing so makes the next item possible...) -
Use
recoll.qrc
directly, instead of duplicating contents -
Configure install
RPATH
s for executables (Note: May need to be reversed, if librecoll.so is moving.) -
Install systemd unit files, using paths probed from pkg-config.
Caveats/disclaimers
-
I haven't tested this on macOS, since I haven't been able to build recoll on macOS. The only macOS system I have access to is a Hackintosh VM running on my Linux desktop, using macOS 10.15 because it's the latest version that runs properly in that environment, and so far getting a build environment that works for recoll has been a challenge. (In part because Homebrew no longer provides packages for 10.15, so I have to build everything myself, sometimes by hand because not all of their recipes are still compatible.) Anyway, point is, fingers crossed that this even might still work correctly, and any mac-related testing is greatly appreciated.
I know there's a lot more the build system could be doing to assist with constructing proper macOS application bundles (mostly via CMake's BundleUtilities module), but without the ability to actually run tests, trying to flesh out that side of things is probably an exercise in futility.
-
As I said, this probably needs to be further tweaked to catch up with the past 2 weeks or so worth of repo changes on the Autoconf side, which I haven't been tracking sufficiently to have incorporated them into this branch. (I rebased the branch onto
master
5 minutes before pushing, it updated cleanly, and that was the extent of my effort to incorporate recent developments.)