Re: USE_LANGUAGES and wrappers

[Greg Troxel <gdt%lexort.com@localhost>]

Havard Eidnes <he%NetBSD.org@localhost> writes:

>> Historically, USE_LANGUAGES+=foo meant "this package needs a foo
>> compile", and that there should be a build dependency on it (perhaps
>> builtin of course).   One example is c++, but another is fortran.
>>
>> This caused the wrappers to fail if a language wasn't in USE_LANGUAGES,
>> in the spirit of bl3 where trying to include or link against something
>> that isn't a declared dependency should fail, even if it is installed.
>>
>> Then things got messy with c++11 etc with setting --std, which can be
>> viewed both as "set --std because the package is buggy and doesn't) and
>> "force a hard fail early if the compiler doesn't do c++11" (on the
>> theory that a compiler must fail if passed --std=foo for some foo not
>> implemented).
>>
>> I think it's widely viewed that this force-std conflation isn't really
>> right.
>
> I agree.  I perceived the introduction of USE_CXX_FEATURES to
> mean that declaration of dependence on a particular numbered
> variant of C++ now belonged in this variable, and that the
> numbered variants should now no longer be used in USE_LANGUAGES.
> That's apparently not where we are at the moment(?)

Not.  Where we are at the moment is (using c++17 without loss of
generality):

  If the package needs a compiler that can compile c++17, then
  USE_CXX_FEATURES must contain c++17.  This is not in any way a bug, if
  the packge's README says that a c++17 compiler is needed.

  If the package needs the compiler to compile c++17 programs when it is
  NOT invoked *by the package* with --std=c++17, then (currently)
  USE_LANGUAGES must contain c++17.  This is always a bug in the
  upstream package -- which may not assume a language default from a
  compiler.

> Another thing that I occassionally stumble upon is that it's not
> guaranteed that you get a working alloca() if you specify any of
> the c++NN variants -- for that you need gnu++NN instead.  This
> gets exposed on NetBSD/powerpc, but not on i386 and amd64,
> because the two latter have a non-compiler-assisted alloca() in
> their libc, while the former does not.  I'm not quite certain how
> to express this in the new scheme of things -- perhaps by using
> gnu++NN in USE_CXX_FEATURES (or USE_CC_FEATURES)?

That should be how you do it.  Or perhaps, adding alloca if we intend to
split beyond-standards gnuisms more finely.

However, it is the program's responsibility to probe for and insert
--std=gnu11 itself.  If a program relies on beyond-standards behavior
without doing that, it's buggy.

Or very very maybe, we could add alloca as a USE_CXX_FEATURES target (or
USE_CC_FEATURES?) and have that force that a good enough compiler is
needed.

We could also use FORCE_CXX_STD (revised suggested name!) to add
--std=gnu11.

> I also don't understand the wrapper implementation, but I sympathise
> with a number of your suggestions:
>
>>   1) Stop having USE_LANGUAGES=c++17 change wrappers.  Or perhaps do
>>   step 2 and warn for now.
>
> Stop using numbered c++ (or gnu++) versions in USE_LANGUAGES also,
> perhaps?  For C++ just do "c++", and let the other settings guide
> the -std= setting? (ref. your #4, below).

Yes, I meant to stop having it do anything, at which point it should no
longer be used.

>>   2) Add a variable FORCE_CXX_VERSION which if e.g. set to c++17 causes
>>   "--std=c++17" to be added by the wrappers.  Basically what
>>   USE_LANGUAGES=c++17 does now.  Maybe -- but I really don't like it --
>>   cause that to get added to USE_CXX_FEATURES.
>
> I slightly dislike this suggestion, it smells too much of
> GCC_REQD which I perceive we're trying to move away from?

I don't follow.  GCC_REQD is bogus because
  - it's about gcc only
  - it results in duplicated knowledge about which gcc version does
  what.

What I'm suggesting is that if a buggy upstream fails to probe for and
use (or just use) --std=c++17 to compile c++17 code, then our
remediation for that should be a declaration that causes the wrappers to
add that --std -- and to make only that change in behavior, disconnected
from anything else.

>>   3) Adjust wrappers so that if e.g. c++17 is not in USE_CXX_FEATURES,
>>   then any invocation with --std=c++17 will fail.
>
> Yes, but I suspect that requires a transition period and possibly
> quite a bit of work (a number of packages will need to be adjusted).

True.  The ones that will need work are the ones that happen to work on
newer compilers that nobody has fixed from older bulk builds.   I bet it
will be pretty fast to fix.  Could be opt in to fail at first.

>>   4) Adjust wrappers to figure out the highest c++ version in
>>   USE_CXX_FEATURES (c++03 if none).  For any invocation *without* an
>>   explicit --std, add --std with that version.  Thus, any program that
>>   is USE_LANGUAGES=c++ but with no c++NN, --std=c++03 will get added.
>
> I like this, it retains the "declarative" flavour of USE_CXX_FEATURES,
> as opposed to an "imperative" flavour of the current USE_LANGUAGES
> when you use a numbered c++ variant there.

I don't see these as differing at all in declarative vs imperative.

It's really about ensuring that builds do not get away with succeeding
if there is a newer default.

Arguably c++ compilers should all force c++03 unless passed --std, and
then upstreams would all get this right.  But that ship has sailed.