Project always installs both shared and static libcutf8-1

[floppym]

I am attempting to package this library for Gentoo Linux.

I would like to install only the shared library libcutf8-1.so, not the static library libcutf8-1.a. Normally this would be accomplished by passing default_library=shared to meson.

However, that does not seem to work for this project. I suspect this is because you are using both_libraries. What is the reason for this? Why not just define it using the normal library function?

[eli-schwartz]

314559c

What it seems to be doing is constructing a usage scenario for using this as a subproject fallback for a wrap file. Usually we (meson upstream) recommend setting default_options: ['default_library=static'] in dependency lookups, or making use of --prefer-static.

Meson provides several different entrypoints into defining libraries to build and install:

• library (default, should be used in most cases)
• static_library (for when it's an error for any other project to depend on you as a shared library, for whatever reason)
• shared_library (for when it's an error for any other project to statically link to you, for whatever reason)
• both_libraries (for when it's an error for any distributor to fail to provide both static and shared libraries)

Each of these last three also correspond to a value for the default_library build option, expressly so that library() can be used for the case of "the user could validly decide which one to use". Its default value is "shared" (not both).

By using any function other than library() you make a concrete statement that anyone who e.g. rm's the static library after meson install is behaving "badly" in some manner that will result in the software itself malfunctioning -- for the same reason that meson will not permit you under any circumstances short of applying a patch to the meson.build file to skip both building and installing the static library. It's not clear to me that that's what you want.

Based on the version before this commit, I get the impression that defaulting to library() but passing default_options for wrap fallbacks should be an adequate solution. Am I missing something?

[dvdhrm]

@floppym So far everyone just bundled c-utils, so we never provided for separate packaging. Is there a particular need to package it separately? (especially given that we haven't been very strict in versioning it)

@eli-schwartz What happens if I have a project with many subprojects, and one pulls in c-utf8 and needs static linking, and another pulls it in but needs dynamic linking. How do I ensure that c-utf8 is then built with default_library=both? I don't want the root-project to be aware of the dependency tree, but for such dependencies to be resolved automatically.

IIUC, using dependency(default_options: ['default_library=XYZ']), it depends on the evaluation order whether this will end up as static or dynamic, am I right? We ended up using both_libraries to ensure this setup always provides both, and packaging was meant to just remove libraries it does not need.

[floppym]

Is there a particular need to package it separately?

It's just a request I received via our issue tracker; we try to avoid using bundled dependencies whenever possible.

https://bugs.gentoo.org/936074

[eli-schwartz]

@eli-schwartz What happens if I have a project with many subprojects, and one pulls in c-utf8 and needs static linking, and another pulls it in but needs dynamic linking.

Is that really likely to happen? Normally, when a library "needs" one or the other it's due to:

• the construction of the library code relying on shared linkage. e.g. you need different source code when linking Qt statically, to force platform / format plugins to be statically linked and initialized at startup
• no stable ABI therefore totally unsafe to do shared linkage

Anyways it looks like as a subproject you always force libcutf8_dep to be static?

How do I ensure that c-utf8 is then built with default_library=both? I don't want the root-project to be aware of the dependency tree, but for such dependencies to be resolved automatically.

build_target() can dispatch on meson.is_subproject() I suppose.

target_type = meson.is_subproject() ? 'both_libraries' : 'library'

build_target(
    'cutf8-'+major,
    ...,
    target_type: target_type,
)

I'm not sure it's actually necessary in your case -- but it definitely allows for you to preserve the current subproject design, while also adapting to the request regarding use as a standalone installable project.

IIUC, using dependency(default_options: ['default_library=XYZ']), it depends on the evaluation order whether this will end up as static or dynamic, am I right?

Yes, though you can also set it in the parent project(default_options: ...) IIRC.