Skip to content

WIP: CMake build changes

FeRD (Frank Dana) requested to merge ferdnyc/recoll:cmake-initial into master

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 under src/ is preferable since that's where the top-level CMakeLists.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, if RECOLL_ENABLE_LIBMAGIC is true.
    • src/cmake/FindFileCommand.cmake - Discover the file binary on the PATH; only used if RECOLL_ENABLE_LIBMAGIC is false.
    • src/cmake/FindSystemdPaths.cmake - Discover the install paths for systemd unit files; only used on Linux, and only if RECOLL_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 variable FileCommand_EXECUTABLE, the location of the magic library can be overridden with Libmagic_LIBRARY, etc.

Project configuration

  • Support building with Qt5 (by default, in fact; RECOLL_QT6_BUILD can be set TRUE 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 to cmake. 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 a QtVersionOption module with some defaulting support that might be helpful; the currently-implemented QT_MAJOR_VERSION variable used to select the version is compatible.)
  • Support building with WebKit if RECOLL_ENABLE_WEBENGINE is OFF (Part of the reason for defaulting to Qt5, it's the only version with QtWebKit support.)
  • Default RECOLL_ENABLE_X11MON to OFF (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 set FILE_PROG, if not using libmagic

Build & Install

  • Set OUTPUT_NAME for librecoll target, to avoid generating liblibrecoll.so. (Note: CMake automatically prepends lib to the output name for library targets. Normally, the target for a library called librecoll would be called recoll and created using add_library(recoll ...) (the lib being implicit). But since we already have a target called recoll, the OUTPUT_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 RPATHs 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

  1. 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.

  2. 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.)

Merge request reports