Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

install target installs libportal #1546

Closed
hfiguiere opened this issue Dec 22, 2024 · 7 comments
Closed

install target installs libportal #1546

hfiguiere opened this issue Dec 22, 2024 · 7 comments
Labels
bug dependency issue This is an issue with a dependency or an upstream project

Comments

@hfiguiere
Copy link
Collaborator

Operating System

Fedora 41

XDG Desktop Portal version

Other

XDG Desktop Portal version (Other)

1.19.1

Desktop Environment

GNOME

Desktop Environment (Other)

No response

Expected Behavior

Doesn't install libportal

Current Behavior

Installs libportal

Installing subprojects/libportal/libportal/portal-enums.h to /usr/include/libportal
Installing subprojects/libportal/libportal/libportal.so.1.0.0 to /usr/lib64
Installing subprojects/libportal/libportal/libportal-gtk3.so.1.0.0 to /usr/lib64
Installing subprojects/libportal/libportal/libportal-gtk4.so.1.0.0 to /usr/lib64
Installing subprojects/libportal/libportal/libportal-qt5.so.1.0.0 to /usr/lib64
Installing subprojects/libportal/libportal/libportal-qt6.so.1.0.0 to /usr/lib64
[...]
Installing symlink pointing to libportal.so.1.0.0 to /usr/lib64/libportal.so.1
Installing symlink pointing to libportal.so.1 to /usr/lib64/libportal.so
Installing symlink pointing to libportal-gtk3.so.1.0.0 to /usr/lib64/libportal-gtk3.so.1
Installing symlink pointing to libportal-gtk3.so.1 to /usr/lib64/libportal-gtk3.so
Installing symlink pointing to libportal-gtk4.so.1.0.0 to /usr/lib64/libportal-gtk4.so.1
Installing symlink pointing to libportal-gtk4.so.1 to /usr/lib64/libportal-gtk4.so
Installing symlink pointing to libportal-qt5.so.1.0.0 to /usr/lib64/libportal-qt5.so.1
Installing symlink pointing to libportal-qt5.so.1 to /usr/lib64/libportal-qt5.so
Installing symlink pointing to libportal-qt6.so.1.0.0 to /usr/lib64/libportal-qt6.so.1
Installing symlink pointing to libportal-qt6.so.1 to /usr/lib64/libportal-qt6.so

Steps to Reproduce

  1. build xdg-desktop-portal
  2. ninja -C _build install

Anything else we should know?

libportal is only a dependency for tests. It should never been installed.

@hfiguiere hfiguiere added the bug label Dec 22, 2024
@github-project-automation github-project-automation bot moved this to Needs Triage in Triage Dec 22, 2024
@GeorgesStavracas GeorgesStavracas added the dependency issue This is an issue with a dependency or an upstream project label Dec 23, 2024
@swick
Copy link
Collaborator

swick commented Dec 23, 2024

This is a bit ugly because with the installed tests we do have to install them. On the bright side, packagers don't use the subproject.

@hfiguiere
Copy link
Collaborator Author

maybe installed tests can only be run with a system libportal...

I haven't found how to tell the subproject to not install though.

@smcv
Copy link
Collaborator

smcv commented Jan 1, 2025

Setting the default options for the subproject to build a static-only library would probably be a good start?

@swick
Copy link
Collaborator

swick commented Jan 7, 2025

meson install has --skip-subprojects which works as advertised. Making the libportal subproject static (default_library=static in dependency default_options) still installs some files:

Installing subprojects/libportal/libportal/portal-enums.h to /usr/include/libportal
Installing subprojects/libportal/libportal/libportal.a to /usr/lib64

It's also not possible to mark the subproject itself with something like --skip-subprojects so those two things are our only options.

Given that I want to remove the C tests which depend on libportal, I'm inclined to leave it to someone else to decide what to do.

@smcv
Copy link
Collaborator

smcv commented Jan 7, 2025

meson install has --skip-subprojects which works as advertised.

If we are using the submodule for libportal, and the tests are dynamically linked to libportal, isn't that going to mean that any "as-installed" tests have a missing runtime dependency and cannot run successfully?

If I'm right about that, then using default_library=static and recommending meson install --skip-subprojects might be a good idea.

Making the libportal subproject static (default_library=static in dependency default_options) still installs some files

We could perhaps mitigate that by making its default options include '-Dprefix=' + (prefix/libdir) + '/flatpak-private', or something, so that it ends up installing usr/lib64/flatpak-private/{include/libportal/*.h,lib64/*.a} on your system, which will not "fight" with other copies of libportal if any?

@smcv
Copy link
Collaborator

smcv commented Jan 7, 2025

This is a bit ugly because with the installed tests we do have to install them.

libportal is just for the tests, am I correct?

On the bright side, packagers don't use the subproject.

Perhaps the build system should just error out in the bad situation:

if libportal_dep.type_name() == 'internal'
  if enable_installed_tests
    error('-Dinstalled-tests=true requires a system copy of libportal')
  endif
  warning('Using libportal subproject, please install using meson install --skip-subprojects')
endif

@smcv
Copy link
Collaborator

smcv commented Feb 14, 2025

This should no longer be the case now that the tests don't use libportal.

@smcv smcv closed this as completed Feb 14, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug dependency issue This is an issue with a dependency or an upstream project
Projects
No open projects
Status: Needs Triage
Development

No branches or pull requests

4 participants