Overhead for uninstalled, static_library targets too great

Describe the bug In order to create groupings of files with different C or C++ compiler flags, IIUC, one must use static_library in Meson and simply not install them. Those libraries can be linked into targets that are.

However, those libraries are not thin and therefore have a high overhead: they occupy as much disk space as the .o files that are included and they take time to create (disk I/O). Ideally, there would be a way to create a “phantom” or “convenience” library (Automake’s term is “convenience”) that cannot get installed and Meson figures out on its own how to deal with it. Maybe it simply passes the listing of .o files to the target that uses them, if it’s linked link_whole.

Or it creates thin static libraries otherwise. See #8057 for a more general case for thin static libraries.

System parameters

• Is this a cross build or just a plain native build (for the same computer)? Native
• what operating system (e.g. MacOS Catalina, Windows 10, CentOS 8.0, Ubuntu 18.04, etc.) Linux
• what Python version are you using? 3.6 to 3.9
• what meson --version: 0.59.1
• what ninja --version if it’s a Ninja build: 1.10.2

[jpakkane]

If you do build_by_default: false and then use extract_objects the .a file should not get built but the .o files are. On the Ninja backend at least as it works with direct file dependencies rather than depending on the .a file.

[eli-schwartz]

Well, it is not obvious but kind of implied, because when you specify a static_libary(..., build_by_default: false) you create:

• a bunch of .c -> .o rules
• a .o -> .a rule

and when you specify build_by_default: false, the .a is not added as a dependency of the default (all) target. And extract_objects() gets you a reference to the individual .o files, which may then be depended on by a build_by_default: true target leaving the .a file as a loosely floating rule which nothing needs and nothing triggers.

It does have its downsides. Adding .o files to an executable will bloat the length of the command line, while depending on a .a file will just add the one file. That being said, when you add one (install: false) static library as a dependency for another (install: true) static library, the second static library needs to have all the code for both libraries at install time, and it links to all the .o files rather than the .a file (which would not work because that is not how ar works). So sometimes you do end up with long command lines either way.