Feature suggestion: add a per-project 'install_tags' option

[DevilishSpirits]

Describe the bug I have a project that statically link to subprojects such as Harfbuzz. To achieve that I must rewrite the Meson build file of my dependencies because they install junk I don't need otherwise.

To Reproduce Create a basic Meson project with default_options: ['default_library=static'],, make a dummy helloworld executable and include a third-party library such as Harfbuzz.

Install and all Harfbuzz libraries/headers/bloat is installed along my standalone helloworld executable.

Expected behavior Only helloworld executable shall be installed.

Feature suggestion Meson provide installation tags that allows packagers and users to filter which part of a project is installed. I suggest adding an option that define which tags should be installed on a per-project basis :

option('install_tags', type : 'array', value : [])

The default empty array would select everything or we could have a special 'all' special value. In my case I would put a dummy ['none'] to exclude everything or if I want to install some files ['runtime','devel']. If a packager use the --tags option, that would filter-out remaining files without the tags (an intersection operation).

• That would fix #10363 as the OP would have to set 'install_tags=[...]'in dependency() default_options array to get the wanted behavior.
• That feature rely on a existing Meson feature and extend it by "adding a per-project filter using Meson option", implementation difficulty is unlikely to be very high.
• It does break projects that defines their own install_tags option. The name should probably be changed (prefixing with reserved b_ ?)
• Existing projects will works exactly as before with this patch (unless see above).
• Existing projects used as subprojects need zero alteration to benefit of the new feature.
• Being a regular Meson project option, users can override this option without editing the sources using all existing ways to manage/override options.
• It allows a "fat /opt software" that ship dependencies wants to unbloat it's installation by not installing parts of it's dependencies using other means than post-installation cleanup.
• It allows standalone application (.exe files that runs everywhere) that statically links with subprojects to installs without bloating (and possibly breaking!) the end-user system.

system parameters

• Is this a cross build or just a plain native build (for the same computer)? N/A
• what operating system (e.g. MacOS Catalina, Windows 10, CentOS 8.0, Ubuntu 18.04, etc.) ArchLinux
• what Python version are you using e.g. 3.8.0 3.10.9
• what meson --version 1.0.1
• what ninja --version if it's a Ninja build 1.11.1

[xclaesse]

That could lead to many inconsistencies, for example if you install devel tag for your main project, chances are your headers include headers from subprojects that also need to install devel tag. If you want to avoid junk, why don't you just install runtime for all (sub)project?

[eli-schwartz]

for example if you install devel tag for your main project, chances are your headers include headers from subprojects that also need to install devel tag.

This is not really true, at all.

It's common for your public headers to include the headers of its dependencies for type primitives, but far far more common to not include the headers of dependencies at all.

Meson can't decide this automatically, but the feature request is for projects to decide that and pass it as dependency('harfbuzz', default_options: ['install_tags=runtime']) or similar.

[xclaesse]

It's common for your public headers to include the headers of its dependencies for type primitives, but far far more common to not include the headers of dependencies at all.

The point is both cases exists, which one is more common does not really matter.

the feature request is for projects to decide that and pass it as dependency('harfbuzz', default_options: ['install_tags=runtime']) or similar.

But it is not up to the project to decide that, it is a user decision what to install. Even if subA does not exposes harfbuzz API, subB could. Making tags global is the safe solution even if it's not a perfect match to all cases.

Maybe extend the --tags syntax like --tags runtime,devel,harfbuzz:runtime? That gives the responsability to the user to know what they do, which is already the case with --skip-subprojects.

[DevilishSpirits]

That could lead to many inconsistencies, for example if you install devel tag for your main project, chances are your headers include headers from subprojects that also need to install devel tag.

I know what I am doing, I statically link all subprojects and it works. Free to my users to override the default behavior, but >90% of them wants the default and expect a meson setup build && meson compile -C build && sudo meson install -C build to "just works".

That gives the responsability to the user to know what they do

They are free to take responsibilities, my suggestion don't alter previous behavior and gives a more granular control to users. But in my case, unless the user read installation instruction, they miss that they need an option to don't break their system, SQLite without thread-safety+30 features is not sane system-wide, this is not an acceptable default for users who don't asked for responsibilities.

My goal with this feature is to allow a developer to provide sane defaults for subprojects installation without altering upstream build-system as I do and a more granular control about what to install.

Maybe extend the --tags syntax like --tags runtime,devel,harfbuzz:runtime?

Alone this won't solve the problem as it's a user-only setting.

[xclaesse]

What is the use case exactly to want to mix devel and runtime installation? Why do you really want that? On any distro for example gtk-dev depends on harfbuzz-dev even if it's not exposed in gtk headers.

Even if libA does not expose libB in its headers, installing devel tag for libA will install liba.a which does need libB.a.

[DevilishSpirits]

My need is to prevent all subprojects from installing artifacts. In my research I found the exact feature request but as stated in https://github.com/mesonbuild/meson/issues/10363#issuecomment-1121222019 :

Subprojects can contain translation files, data files, etc that are still needed a runtime even when it's static linked. That's why we now have --tags runtime instead that is more fine grained.

So I thought about a finer-grained solution to cope with this situations.

[Akaricchi]

Fully support the feature request, I'm in a very similar situation with Taisei Project. The lack of control over what gets installed is a major reason I can't rely on the wrapdb.