-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
subproject installs when project using it installs #2550
Comments
It'd better to add a meson commond options to control this behavior. install library and exectuable of a subproject is useful at most time. For example , I want to cross compile a package to a target device, I also need install all dependency libraries. another example, when build a package run in docker, usually, the system run in docker is minimum, so it'd better ship all dependency library with you package. |
In this case, the "main project" has a dependency on the subproject. The subproject explicitly does not need to be available on the system; Meson will download the subproject from Git, compile it and use it. In my opinion, with the above case (dependency not available system wide, so Meson grabs subproject to resolve, and uses locally), it does not make sense to install the subproject along with the main project, when Does that explain my logic better? |
Ok; i think I need to be more specific: when doing shared libraries, they must be installed too. Static linking however, it is probably not required. Hmm. Yet another complication. I don't know the right answer. |
if subprojects provide pkg-config file, you can workaround like this:
|
In the mean time projects can ask whether they are being built as subprojects with |
This would need a new command like |
We now have |
I think we actually already can know if something from a subproject needs to be installed and install it accordingly, if the target is used by the main project and is a shared library install it, otherwise don't. the only really tricky bit is data, since we can't know if the library needs to use that data at runtime. |
Maybe meson should just not install subprojects by default, and instead set Having any project install random (possibly unstable) versions of shared libraries for system-wide use could cause various compatibility and security issues. Also, since subprojects are also uninstalled when the parent project is uninstalled, uninstalling a project that has a shared library subproject will unexpectedly break other programs and libraries on the system that were installed later and use the same shared library. |
I would like to have some control, which subproject is installed and which is not. I believe there is a large variety of use cases and an implicit logic might not fit. The current behavior, that all subprojects are installed by default, is tricky. Let's think of an external test framework that is used as a subproject via some wrap file. The test framework, which is used to write unit tests only, will be installed on the system, when the project is installed. Is suppose, that is not what's intendet mostly. Otherwise, I can imagine to create a project that provides a set of libraries. Subprojects may be used for structuring purposes. The Boost library is an example for such a kind of project (although it is not a meson project). Therefore, I believe, a build system cannot know implicitly , which subproject should be installed and which should not. But I, as a project author, do know what I want and I want to be able to describe it in my (In contrast to prior posts in this thread, it would prefer to not change existing behavior, if possible) |
Or, subprojects should only build statically, because it's quite unlikely you want to install conflicting goop to /usr and if you're using private copies of your dependency you probably want them to be, well, private. Required data files have been mentioned in the past, and here too I'd argue you do not want to conflict the system versions of such files; in order to robustly implement such a wrap it would need to be configurable where this data is expected to be found, and point it to a superproject-specific private directory in the subproject options in meson.build. But under no circumstances EVER should a subproject install directly to the superproject's --prefix. Shared, static, data or otherwise. (Unless you're using a toplevel meson.build merely to list a bunch of subprojects as a meta-build system to build a bunch of projects in parallel, which I believe some people do, but this should be opt in, not opt out. Currently meson's default behavior assumes this very exclusive use case is the default way to install things. It's therefore impossible to use subprojects sanely without gating install logic behind meson.is_subproject().) |
FWIW, this is how GStreamer is built for development purposes, and for targeting certain embedded environments. |
On linux and other *nix systems this is true. But for OSes like Windows you're expected to bundle all of your dependencies up and plop them in |
I'd consider that to be a private prefix/libdir. :) |
Do we really want to attempt to do some kind of automagic figuring out what bits from the subprojects "need" installing based on dependencies? I would contend that that's pretty much doomed to make everyone unhappy. I don't think it's possible to make things work right automagically for all the different use cases / scenarios people have. Which IMHO means it has to be left to the person doing the installing. How about something like:
Plus perhaps (suggested by various people elsewhere):
|
Or I guess that could be expressed in a simpler way by installing everything by default and adding options for type tags and subprojects to |
Oh my bad, sorry for the noise. I knew I had seen this before somewhere 😊 |
That's why I said:
Ideally subprojects would default to not install (except on Windows), and developers could whitelist the things they need installed from the superproject (perhaps using a list of tags as discussed in the other issue). Or they could override the options and tell the subproject to install, using a custom prefix/libdir option. For library(), the state of default_library is a pretty good heuristic for whether you want to install it as a subproject. But meson could just force people to be explicit. |
The os has nothing to do here. On Linux I build gstreamer with tones of subprojects, all shared libraries, with /urs as prefix, but with DESTDIR at installation, then I can copy those files from build machine to my devices. In any case, 'ninja install' is an alias to 'meson install', and should always install everything from all subprojects for backward compatibility, there is no reason to change that. We can add options to 'meson install' for more flexibility of course, I like the idea of tags, we can also add --no-subproject, or --only-subprojects=list, why not. |
It seems this use case is undesirable. Please close this as WONTFIX so people know what they're getting into when they consider using meson subprojects. |
What I mean is you can't install stuff in You're over simplifying the problem by thinking that static link subprojects and not install anything will just work. That's not true. Subprojects could install data files (e.g. i18n, images, etc). Your use-case is perfectly valid, and I worked hard to make This issue is definitely not a WONTFIX, I totally support the idea of adding |
As I'm currently experiencing this issue, I support the idea of adding |
I'm having this issue as well. I believe a common use-case for subprojects is to build libraries if they are not found on the user's system (say gtk). you don't want to be installing gtk along with your program though.
I like this idea. or pass it to |
I think this really needs a user-level switch first. There are lots of people with different use cases. In addition to that it might make sense to also provide a way for projects to always opt out of installing by passing |
Sure, user-level switch would be also nice. So let say we have the project structure like:
Then being able to override the settings done via |
By default all subprojects are installed. If --skip-subprojects is given with no value only the main project is installed. If --skip-subprojects is given with a value, it should be a coma separated list of subprojects to skip and all others will be installed. Fixes: mesonbuild#2550.
Since this is a popular request but nobody tried to make a PR, I gave it a try: #8356. |
By default all subprojects are installed. If --skip-subprojects is given with no value only the main project is installed. If --skip-subprojects is given with a value, it should be a coma separated list of subprojects to skip and all others will be installed. Fixes: mesonbuild#2550.
By default all subprojects are installed. If --skip-subprojects is given with no value only the main project is installed. If --skip-subprojects is given with a value, it should be a coma separated list of subprojects to skip and all others will be installed. Fixes: mesonbuild#2550.
By default all subprojects are installed. If --skip-subprojects is given with no value only the main project is installed. If --skip-subprojects is given with a value, it should be a coma separated list of subprojects to skip and all others will be installed. Fixes: mesonbuild#2550.
By default all subprojects are installed. If --skip-subprojects is given with no value only the main project is installed. If --skip-subprojects is given with a value, it should be a coma separated list of subprojects to skip and all others will be installed. Fixes: mesonbuild#2550.
By default all subprojects are installed. If --skip-subprojects is given with no value only the main project is installed. If --skip-subprojects is given with a value, it should be a coma separated list of subprojects to skip and all others will be installed. Fixes: mesonbuild#2550.
By default all subprojects are installed. If --skip-subprojects is given with no value only the main project is installed. If --skip-subprojects is given with a value, it should be a coma separated list of subprojects to skip and all others will be installed. Fixes: mesonbuild#2550.
By default all subprojects are installed. If --skip-subprojects is given with no value only the main project is installed. If --skip-subprojects is given with a value, it should be a coma separated list of subprojects to skip and all others will be installed. Fixes: mesonbuild#2550.
By default all subprojects are installed. If --skip-subprojects is given with no value only the main project is installed. If --skip-subprojects is given with a value, it should be a coma separated list of subprojects to skip and all others will be installed. Fixes: mesonbuild#2550.
By default all subprojects are installed. If --skip-subprojects is given with no value only the main project is installed. If --skip-subprojects is given with a value, it should be a coma separated list of subprojects to skip and all others will be installed. Fixes: mesonbuild#2550.
By default all subprojects are installed. If --skip-subprojects is given with no value only the main project is installed. If --skip-subprojects is given with a value, it should be a coma separated list of subprojects to skip and all others will be installed. Fixes: mesonbuild#2550.
By default all subprojects are installed. If --skip-subprojects is given with no value only the main project is installed. If --skip-subprojects is given with a value, it should be a coma separated list of subprojects to skip and all others will be installed. Fixes: mesonbuild#2550.
By default all subprojects are installed. If --skip-subprojects is given with no value only the main project is installed. If --skip-subprojects is given with a value, it should be a coma separated list of subprojects to skip and all others will be installed. Fixes: #2550.
By default all subprojects are installed. If --skip-subprojects is given with no value only the main project is installed. If --skip-subprojects is given with a value, it should be a coma separated list of subprojects to skip and all others will be installed. Fixes: mesonbuild#2550.
How to use ninja call |
|
Modern Meson wants the "setup" subcommand to be used explicitly. In order to install only our project's files instead of all headers and libraries from the subprojects, we need to use a Meson command directly instead of calling ninja [1]. [1] mesonbuild/meson#2550
As from the IRC log just now:
HarryHaaren | hey all, any advice for when using a library subproject, should "install" be the default for the library? eg: project X uses subproject Y (as above, with install as default) ninja install of project X will also cause subproject Y to be installed globally next time project X has "meson build" run, it picks up the globally installed copy of subproject Y, instead of using the subproject Git method. This causes problems when configuring and installing multiple times.
Current solution is to mark the library "install : value" of the subproject to be false if
meson.is_subproject()
Does that sound reasonable? (need to be careful with install_headers() and others too..) confirmed the above works. https://github.com/openAVproductions/openAV-Avtka/blob/master/meson.build#L31 (and #52 to notinstall headers either)
It places the burden of not polluting the system on a subproject - I think it would be cleaner if the "main project" could set to not install any of its subproject dependencies (especially when statically linking this makes sense).
Just noting my woes, and the solution above. Feel free to close this issue if the above solution is the recommended one.
The text was updated successfully, but these errors were encountered: