Convert NO_SHARED to MK_SHARED and make a first class bsd.opts.mk consumer

[ngie]

Summary

Convert NO_SHARED to MK_SHARED and make a first class bsd.opts.mk consumer

This changes NO_SHARED (a knob that doesn't conform fully to NO_*) a proper MK_*
knob and allows others to customize behavior/rely on MK_SHARED being set to control
other knob behavior. For example, I discovered that MK_COVERAGE in
^/projects/runtime-coverage doesn't play well with NO_SHARED.

MFC after: 1 month
Relnotes: yes (NO_SHARED might be used by downstream consumers)

Test Plan

• Buildworld/installworld.
• Verified that end-results for binaries, like as(1) were consistent with previous versions of FreeBSD (was static before; remained static now).

[ngie]

Add WITHOUT_SHARED src.conf(5) blurb

[ngie]

Remove accidental diff for libexec/rtld-elf/Makefile

[imp]

I really really don't like this.

NO_SHARED isn't like a MK_XXX variable. The MK_XXX variables are generally considered to be invariant in the tree. Makefiles generally shouldn't be setting them (except for buildworld related things). NO_SHARED, however, is expected to be set throughout the tree to differing values. So this fails two different tests: MK_XXX being set in makefiles (which is verboten) and MK_XXX being set to different things in the tree (which is highly undesirable, though you might find one exception someone talked me into).

This is an ill-advised changed and I say don't make it, at least not in it's current form.

It doesn't help that NO_SHARED is overloaded to mean globally "don't build shared libraries or link to them' and locally to mean either 'always link static' or 'don't build dynamic libraries'. And it's a bit inconsistent since there's NO_SHARED=no to override (which itself makes it unique, since all the other NO_xxx variables that remain are existence variables).

So, while I welcome the cleanup, it's done wrong in several ways. We need a declarative way for makefiles to say "override whatever the global setting is and do/don't do shared here" and also a user-visible knob that says 'disable / enable shared libraries globally' though these days, a static works is somewhat deficient in functionality, though for some users that's OK.

And yes, there's many users of NO_SHARED outside the tree that push the envelope on what's considered good taste and which make changing this flag especially traumatic for downstream consumers.

[ngie]

In D11903#246797, @imp wrote:

I really really don't like this.

NO_SHARED isn't like a MK_XXX variable. The MK_XXX variables are generally considered to be invariant in the tree. Makefiles generally shouldn't be setting them (except for buildworld related things). NO_SHARED, however, is expected to be set throughout the tree to differing values. So this fails two different tests: MK_XXX being set in makefiles (which is verboten) and MK_XXX being set to different things in the tree (which is highly undesirable, though you might find one exception someone talked me into).

MK_XXX is already set in some Makefiles -- for example, lib/libc*/Makefile and libexec/rtld-elf/Makefile .

This is an ill-advised changed and I say don't make it, at least not in it's current form.

It doesn't help that NO_SHARED is overloaded to mean globally "don't build shared libraries or link to them' and locally to mean either 'always link static' or 'don't build dynamic libraries'. And it's a bit inconsistent since there's NO_SHARED=no to override (which itself makes it unique, since all the other NO_xxx variables that remain are existence variables).

So, while I welcome the cleanup, it's done wrong in several ways. We need a declarative way for makefiles to say "override whatever the global setting is and do/don't do shared here" and also a user-visible knob that says 'disable / enable shared libraries globally' though these days, a static works is somewhat deficient in functionality, though for some users that's OK.

And yes, there's many users of NO_SHARED outside the tree that push the envelope on what's considered good taste and which make changing this flag especially traumatic for downstream consumers.

So... just to clarify:

1. You want me to rename NO_SHARED to something other than NO_SHARED? I'm guessing the Makefile and the Makefile.inc1 parts are portions which are problematic, along with bsd.prog.mk..?
2. You want a backwards compatible way of specifying NO_SHARED: technically it handled "no" and "NO", and everything else was considered false, i.e., "don't build shared".

Alternatively, are you looking for a parallel solution to bsd.opts.mk (something that leverages bsd.mkopt.mk) which effectively handles NO_* (or a similar idiom) in a consistent way?

[imp]

In D11903#246800, @ngie wrote:

In D11903#246797, @imp wrote:

I really really don't like this.

NO_SHARED isn't like a MK_XXX variable. The MK_XXX variables are generally considered to be invariant in the tree. Makefiles generally shouldn't be setting them (except for buildworld related things). NO_SHARED, however, is expected to be set throughout the tree to differing values. So this fails two different tests: MK_XXX being set in makefiles (which is verboten) and MK_XXX being set to different things in the tree (which is highly undesirable, though you might find one exception someone talked me into).

MK_XXX is already set in some Makefiles -- for example, lib/libc*/Makefile and libexec/rtld-elf/Makefile .

That's almost certainly in error. I do sweeps of the tree every few months to eliminate MK_ set in makefiles. The ones that are there now are for every special cases that can't be easily done in any other way, at the moment, and this is a temporary workaround. I do not want to see more of them in the tree. We've been pretty good at policing this for many maybe 15 years and I don't want to stop now.

This is an ill-advised changed and I say don't make it, at least not in it's current form.

It doesn't help that NO_SHARED is overloaded to mean globally "don't build shared libraries or link to them' and locally to mean either 'always link static' or 'don't build dynamic libraries'. And it's a bit inconsistent since there's NO_SHARED=no to override (which itself makes it unique, since all the other NO_xxx variables that remain are existence variables).

So, while I welcome the cleanup, it's done wrong in several ways. We need a declarative way for makefiles to say "override whatever the global setting is and do/don't do shared here" and also a user-visible knob that says 'disable / enable shared libraries globally' though these days, a static works is somewhat deficient in functionality, though for some users that's OK.

And yes, there's many users of NO_SHARED outside the tree that push the envelope on what's considered good taste and which make changing this flag especially traumatic for downstream consumers.

So... just to clarify:

1. You want me to rename NO_SHARED to something other than NO_SHARED? I'm guessing the Makefile and the Makefile.inc1 parts are portions which are problematic, along with bsd.prog.mk..?

No. I want you to split the two different concepts apart. The 'I can't be built as shared, even when requested' in a makefile is different than 'I'd like a system to not be shared'. NO_SHARED straddles both worlds now, especially since it can appear in Makefile.inc to partition the tree into shared and static parts. Each part will have different expressions.

2. You want a backwards compatible way of specifying NO_SHARED: technically it handled "no" and "NO", and everything else was considered false, i.e., "don't build shared".

That would be nice, but it's tricky....

Alternatively, are you looking for a parallel solution to bsd.opts.mk (something that leverages bsd.mkopt.mk) which effectively handles NO_* (or a similar idiom) in a consistent way?

No. The NO_* options are declarative options, not user turnable knobs. NO_SHARED is one of the last remaining ones that straddles both worlds (NO_CLEAN being the other).

[bdrewery]

MK_PROFILE feels similar to the NO_SHARED discussion to me. I'm not sure what I think either way overall here.

[imp]

In D11903#247094, @bdrewery wrote:

MK_PROFILE feels similar to the NO_SHARED discussion to me. I'm not sure what I think either way overall here.

It kinda is, and kinda isn't. It's a little similar, but it's scope is much reduced. There's only a couple of normal libraries that turn off profiling because they are special libraries (and OFED for reasons that are likely bogus) and those libraries can't be compiled with profiling because they are too low level. It doesn't have the mixup between being a user knob, being a subtree knob and being a declarative statement for certain binaries and libraries to detangle.

[ngie]

I'm abandoning the revision due to concerns from @imp . Will definitely keep it in mind if I need to revisit this with a similar patch.