Generate shared library
jonathanspw opened this issue · comments
Is it possible to generate a shared library instead of just a static one? Using static libs in major Linux distros is generally frowned upon.
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_packaging_static_libraries
NFDe has always been intended to be a thin and small static library compiled into the user application, but I can see how a shared library might be desired for distros. I will need some time to investigate if and how to generate a shared library properly, and figuring out if and when this should be the recommended way to do things (e.g. For Linux packages only? For all Linux builds? What about MacOS and Windows builds?).
Do you mind making a PR for this, if it's just a small CMakeLists change? I know NFDe has already made its way into some Linux distributions, such as Gentoo. They seem to have only removed STATIC from the add_library() CMake command.
If this is to become a package, there's probably also the question of whether it should use GTK or portals. There's probably less drawback to using portals when packaged, since you could probably specify that this package depends on the xdg-desktop-portal package and at least one portal backend (or at least, you will know if your distro comes with the portals stuff already set up).
That does seem to make it generate a shared library, thanks for finding that! I'm not a pro at making/editing CMake files, I just package them with minor patches from time to time.
The curent idea for Fedora is to generate a package built upon each, GTK and portals, though I'm not sure how we're going to accomplish that and I'm waiting on feedback/advice from some other packagers.
The problem I'm trying to solve here is in ImHex's's usage of this library. Currently there are issues with different WMs. ImHex's included version of this lib builds for portals by default but I've had reports that doesn't work with KDE.
ImHex added in the ability to build against a system lib of NFD so we are packaging it in Fedora so we can hopefully solve the issue for anything else that might use the lib in the future too to work across all DEs, or at least as many as possible.
The shared library that it does generate is not versioned, and we need it to be.
ImHex's included version of this lib builds for portals by default but I've had reports that doesn't work with KDE.
Hmm, I'm only aware that portals don't work out of the box on Arch because Arch doesn't come with xdg-desktop-portal pre-installed.
The curent idea for Fedora is to generate a package built upon each, GTK and portals, though I'm not sure how we're going to accomplish that and I'm waiting on feedback/advice from some other packagers.
I don't know much about packaging on Linux, but wouldn't it make more sense that the distro maintainers decide if they want to support GTK or portals? The application developers won't really know whether portals will work on a particular distro, but the distro maintainers would. So distro maintainers get to decide whether to build the nfd package with GTK or portals; if built with portals, it's guaranteeing that the portal dependencies will be available, and if build with GTK, it's guaranteeing that the GTK dependencies will be available. But it doesn't matter to the application because it just links with libnfd.so.
Hmm, I'm only aware that portals don't work out of the box on Arch because Arch doesn't come with xdg-desktop-portal pre-installed.
I did some testing and it works fine with KDE.
What would you think about generating different lib names for gtk vs portal so that both can coexist without conflict?
I think the cmake OUTPUT_NAME target property should do that, but ideally we want to set it on the command line so that the build doesn't generate different lib names by default.
(But it does feel like application developers will be in a worse position than you in deciding whether they should use GTK or portal on your DE.)
I'm not sure that using a cmake target property is ideal. Shouldn't the names be known for other developers to use?
Building NFD twice to provide both the GTK and portal interfaces for other packages was my idea when we were discussing the Fedora package for NFD with @jonathanspw . But I am not sure it was a good idea :-) I think at the end it might be better to build just the GTK variant as a distro package, there should be a theme to make it visually closer to the QT interface for eg. KDE users, it's used for other GTK-based apps already.
Hmm I'm not sure if applications would like using GTK though - even though NFDe uses GTK by default, there are some other projects I know of that explicitly made the choice to use portals: https://github.com/btzy/nativefiledialog-extended/wiki/Native-File-Dialog-Extended-in-the-wild
I don't think this would be a problem, those listed apps likely use bundled NFDe and they can pick their choices. The problem with the portal is that when the portal support package(s) are not installed, then there is no information given to the user about the problem. I have met that with ImHex, clicking on "Open File" did simply nothing, no file dialog, no message. Also different desktops need different portal packages matching the UI so it can't be easily expressed with package dependencies. Thus having the NFDe package provide a GTK interface is a safe option.
I see, thanks for clarifying.
Yep let's just merge the PR and we'll build the GTK variant in Fedora.
I talked with @WerWolv from ImHex and the only reason he swapped to portals was to not have to ship GTK deps in AppImage and Flatpak.
GTK should be more universally usable so that's all I'm going to ship.
Yep let's just merge the PR and we'll build the GTK variant in Fedora.
I talked with @WerWolv from ImHex and the only reason he swapped to portals was to not have to ship GTK deps in AppImage and Flatpak.
yup, here makes the portal interface fully sense
GTK should be more universally usable so that's all I'm going to ship.
#76 has been merged.