Wanted: ability to avoid building redpanda .a files

[travisdowns]

As far as I can tell a cc_library target will produce an .a as its output, but in the case that your linker supports --start_lib --end_lib, these .a files aren't even used by the rest of the build: as the constituent .o files are used instead. So we have these .a files almost doubling the disk use by the bazel build (for build types using enough dynamic linking where most space is used by .o files, not the final binaries), and in CI when we use remote caching and do a bazel build //... it spends half of its time downloading these .a files which aren't used.

I can see a few options:

1. For compatible toolchains stop every building the .a file, they would no longer be an output of the cc_library rule (probably a big change, hard for various reasons).
2. Offer a mode which allows you to filter out the .a targets specifically, so when using a wide build spec like //... they are not built (but the .o files will mostly all be built as they are dependency for targets which need them).

Perhaps (2) could already be the basis of a workaround: somehow filter out all the library targets from a build and build the remaining targets, probably possible with one of the query commands.

I wasn't sure if this should go here or in the main bazel repo, LMK if it's in the wrong place.

[trybka]

AFAIK if your toolchain has supports_start_end_lib feature enabled, archiving actions are not run.

Can you provide a reproducer?

[keith]

I think this is because start/end lib don't affect the DefaultInfo for the cc_library rule?

https://github.com/bazelbuild/bazel/blob/5c29cc34d5deb6f6ff868c1bef9acb1ca0a74eda/src/main/starlark/builtins_bzl/common/cc/cc_library.bzl#L242-L246

https://github.com/bazelbuild/bazel/blob/5c29cc34d5deb6f6ff868c1bef9acb1ca0a74eda/src/main/starlark/builtins_bzl/common/cc/cc_library.bzl#L310-L311

[trybka]

I missed the part where you're building //... which would build the cc_library targets directly. My mistake.

I don't know that we have a great answer here except that building libraries directly can be an anti-pattern (e.g. they need to be built correctly in the configuration of a transition or something). But the ideal is not well supported (i.e. //... is going to build libraries).

We can keep this open to consider possibilities. Perhaps cc_library could/should take that feature into account in assembling the DefaultInfo.

[keith]

I imagine having cc_library return the objects instead of the archive would be pretty trivial if we wanted

[fmeum]

I imagine having cc_library return the objects instead of the archive would be pretty trivial if we wanted

Yes, doing that depending on the presence of start-lib/end-lib support sounds correct to me.

[travisdowns]

@trybka wrote:

AFAIK if your toolchain has supports_start_end_lib feature enabled, archiving actions are not run.

Can you provide a reproducer?

Given the subsequent replies, are you still looking for a reproducer? I am pretty sure a trivial hello-world project with clang as the compiler reproduces this.

[trybka]

Nope. My misunderstanding of the initial request.

[keith]

this works #493 but maybe we still want to give some way for people to produce the static lib?