lirios / cmake-shared

:book: Shared CMake functions and macros

Liri

This repository contains:

• Manifest files for developers.
• General issue tracker.
• Backers list.
• Wiki.

Contributor Guide

Please read the detailed contributor guide.

General issue tracker

Click on the Issues tab and submit issues.

Wiki

Click on the Wiki tab, read and/or write new content.

Alternatively you can clone the Wiki repository, work on your local system and push the changes back.

Clone the repository with:

git clone [email protected]:lirios/lirios.wiki.git

cmake-shared's Issues

LiriAddModule: improve forwarding headers handling

Add more flexibility allowing the user to specify multiple class names and even the path to the header file.
Both things are optional, the previous behavior is still respected.

Qt Quick Compiler support

Add support to Qt Quick Compiler automatically to all products that have resources.
See https://doc.qt.io/QtQuickCompiler/qquickcompiler-building-with-cmake.html

INSTALL_PLUGINSDIR should be the result of QT_INSTALL_PLUGINS (from qmake -query) instead of "${INSTALL_LIBDIR}/plugins"

This will make it more compatible with distros that build their qtbase with a custom archdatadir, I think this must be what KDE does

I can work around it with -DINSTALL_PLUGINSDIR to not have to pass a QT_PLUGIN_PATH

but it makes it compatible with say archdatadir /opt/lib/$DEB_HOST_MULTIARCH/qt5/ in a multiarch layout, and coinstallability with Qt6

Windows Installation

i think making in windows is only possible with cmake -G "Unix Makefiles" .., i couldnt make -G "NMake Makefiles" nmake gives this error :

Extension(s) (.PHONY) not defined

Disable Java style iterators

Java style iterators are going to be deprecated.
Add -DQT_NO_JAVA_STYLE_ITERATORS

Code coverage

Add code coverage for Clang and GCC.

Remove obsolete modules

Some modules are now obsolete with Qt 6.
Other modules will be replaced by ECM or the complexity is so low that it does not justify maintaining a module here.

Here's the list:

• LiriAddQmlModule
• LiriAddQmlPlugin
• LiriAddPlugin
• LiriAddExecutable
• LiriAddTest
• LiriAddStatusAreaExtension - move to liri-shell?
• LiriAddSettingsModule - move to liri-settings?

Enable C++ 17

It's 2022, compilers should support it now. Besides at some point we are gonna build against Qt 6 which requires it.

plugins.qmltypes gets removed

Because it's generated in the source directory, so a make clean will remove it.
Generate it in the binary directory.

Something seems wrong with linking

Just sent out [1] on eglfs. Think that is OK - starting liri session produces more content in log file than before but now I get:

GLib-GIO-Message: 21:29:49.759: Using the 'memory' GSettings backend. Your settings will not be saved or shared with other applications.
liri.logind: Session path: "/org/freedesktop/login1/session/c5"
liri.logind: Acquired control of the session
No usable crtc/encoder pair for connector "Composite1"
liri.qpa.input: logind connection established
liri.qpa.input: Initializing libinput
liri.qpa.input: event0 - HID 04d9:1133: is tagged by udev as: Mouse
liri.qpa.input: event0 - HID 04d9:1133: device is a pointer
liri.qpa.input: event1 - USB Keyboard: is tagged by udev as: Keyboard
liri.qpa.input: event1 - USB Keyboard: device is a keyboard
liri.qpa.input: event2 - USB Keyboard: is tagged by udev as: Keyboard
liri.qpa.input: event2 - USB Keyboard: device is a keyboard
liri.qpa.input: Assigned seat "seat0" to udev
liri.qpa.input: Setting up libinput
== Liri Shell v0.9.0 ==
** http://liri.io
** Bug reports to: https://github.com/lirios/shell/issues
** Build: 0.9.0-tarball
OS: Mortsgna v0.1 [linux version 4.14.81-rt47]
Architecture: arm; features: Neon
Platform name: liri
liri.loginmanager: Using "logind" login manager backend
liri-shell: symbol lookup error: /usr/lib/libLiri1EglFSDeviceIntegration.so.1: undefined symbol: FcPatternCreate

FcPatternCreate?? - It is some fontconfig function - what the hell does liri-eglfs want with it?

It is something to investigate: I have the feeling that libraries build with the help of liri-cmake-shared
are linked incomplete - dependencies seem to be missing. This is just a guess...

[1] liri-archive/eglfs#7

Allow static plugins

Add STATIC argument to liri_add_qml_plugin and liri_add_plugin.

LiriAddModule: automatic list of class name for forwarding headers

In the quest for an easier way to define modules, we now want to automatically detect class names for the public headers in the SOURCES list.

LiriAddModule: autogenerate private headers list

We want to make it easier to create modules: since private headers are already in the SOURCES list we should be clever and figure out automatically which headers are private.

The rule is simple: those that match this regular expression _p.h$ are private headers.

Of course, we let users manually specify the private headers list with PRIVATE_HEADERS if they wish.