Re: USE_LANGUAGES and wrappers

[Havard Eidnes <he%NetBSD.org@localhost>]

Hi,

and thanks to you too for flagging these issues.

> 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(?)

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)?

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).

>   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?

>   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).

>   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.

Regards,

- Håvard