Create a cmake build system

[letsfindaway]

Sooner or later it will be required to switch to a cmake based build system due to the following reasons:

• qmake will be deprecated and cmake is the replacement supported by Qt.
• quazip for Qt 6 cannot be found using pkgconfig, because Qt 6 < 6.3.1 does not provide pkgconfig files.

There s already basic work for that on nextboard which can be used as a basis. From that starting point the following things would be necessary or useful:

• Adapt it to the 1.7-dev branch.
• Structure the single CMakeLists.txt file into smaller units for
  • platform specific stuff,
  • subdirectories,
  • library references.
• Allow to use it with both, Qt 5 and Qt 6.

[letsfindaway]

Structure of the cmake files

I'm trying to create a structure of cmake files with the following targets in mind:

• Easy to understand.
• Easy to maintain.
• Covering Linux, Windows and MacOS platforms.
• Allow to build for Qt5 and Qt6 without modifying the cmake files.
• Reasonable structure in QtCreator.

The main CMakeLists.txt file should be concise, but still contain the most important settings. It might consist of the following sections:

• Basic project information: name, version.
• Definition of options, e.g. for Qt version, 3rd party libraries.
• Basic compiler settings: C++ version, AUTOMOC, AUTOUIC.
• Location of non-source files: resources, i180, library, etc, and others.
• Managing project dependencies.
• Adding subdirectories.
• Processing resources and translations.
• Installation.

What should be in included cmake files:

• Platform specific stuff and all platform switches.
• Finding dependencies.

What should be in subdirectory CMakeLists.txt files:

• List of source file names.
• Dependencies specific to that subdirectory.
• Contributions to the include path.

The third-party repository shall become obsolete. If an external dependency cannot be imported from the platform but should be built and bundled, then this shall be done via FetchContent.

[jbruechert]

Putting the dependencies in the root CMakeLists.txt also has value, it makes it a lot easier for packagers to find a complete list of dependencies. In KDE we have the (informal?) policy to put all dependencies there for that reason.

FetchContent should always be optional IMO, since it would need network access at build time which is not the case for flatpak and not for many other distribution package builders either.

[letsfindaway]

Thanks for your comment!

Putting the dependencies in the root CMakeLists.txt also has value, it makes it a lot easier for packagers to find a complete list of dependencies. In KDE we have the (informal?) policy to put all dependencies there for that reason.

That is true. With OpenBoard, the dependencies vary with the platform (e.g. FFmpeg or the Windows Media stuff). So there will be quite some if()'s. I'm currently trying to collect all these things in a file included in the main CMakeLists.txt. Let's finally decide whether it is better to "inline" this file to make dependencies more explicit.

FetchContent should always be optional IMO, since it would need network access at build time which is not the case for flatpak and not for many other distribution package builders either.

I would only use FetchContent for platforms where some dependencies have to be bundled, e.g. Windows, to replace the current ThirdParty stuff. For Linux I would like to avoid bundling libraries with the application packages. Flatpacks are another story and will not use FetchContent. But I would probably have something like

if(WIN32)
    include(cmake/FetchContentQuaZip.cmake)
else()
    include(cmake/FindPackageQuaZip.cmake)
endif()

For Xpdf (needed for Windows) this approach currently fails, because the build files contained in the original Xpdf source package do not create an Xpdf library, but only the executables. Don't know how to approach this without creating and maintaining again something like OpenBoard-ThirdParty.

[jbruechert]

Maybe at this point it would be easier to use poppler on windows too?
I guess it doesn't really have any disadvantages, since the Xpdf copy is basically just a very outdated copy of the same files.

[letsfindaway]

Good idea! Was now trying to FetchContent of poppler, but this fails with the following errors:

CMake Error at test/_deps/poppler-src/CMakeLists.txt:7 (include):
  include could not find requested file:

    PopplerDefaults


CMake Error at test/_deps/poppler-src/CMakeLists.txt:8 (include):
  include could not find requested file:

    PopplerMacros

and some more. When looking at the poppler CMakeLists.txt, it does the following:

set(CMAKE_MODULE_PATH ${CMAKE_SOURCE_DIR}/cmake/modules)

include(PopplerDefaults)
include(PopplerMacros)

is ${CMAKE_SOURCE_DIR} set to something different when building via FetchContent? Any idea?

[letsfindaway]

See https://github.com/letsfindaway/OpenBoard/tree/add-cmake-build-system for some initial work on this topic.

[letsfindaway]

Currently the UI forms are not visible in the Qt Creator user interface. Also other resource files like the global configuration file are not listed there. We should define them in a way that they are detected by Qt Creator and can be edited from the IDE.

Edit: added them now as sources. They are then visible below CMake-Module. Not the best place but CMake seems to have no support for non-programming-language source files. Also the translation .ts files are not visible.

[letsfindaway]

Putting the dependencies in the root CMakeLists.txt also has value, it makes it a lot easier for packagers to find a complete list of dependencies. In KDE we have the (informal?) policy to put all dependencies there for that reason.

This makes sense. Moved the content of Dependencies.cmake to the main CMakeLists.txt.