Re: CVS commit: pkgsrc/cad

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

nia <nia%NetBSD.org@localhost> writes:

>> > > >  USE_PKGLOCALEDIR=     yes
>> > > >  USE_LANGUAGES=                c c++17
>> > > 
>> > > Should this be changed to 
>> > > USE_LANGUAGES=           c c++
>> > > ?
>> > 
>> > Don't know. Needs testing.
>> > 
>> > If it builds successfully with
>> > USE_LANGUAGES=     c c++03
>> > 
>> > then that means
>> > USE_LANGUAGES=     c c++
>> 
>> Then there's something I didn't get; I though c++17 was supposed to be in
>> USE_CXX_FEATURES now, not in USE_LANGUAGES ...
>
> USE_LANGUAGES+=       c++17 does the same thing it always did
> (forces the wrappers to insert -std=c++17). Sometimes it's necessary,
> most of the time not.

Yes, in terms of what it actually did, but it's different in terms of
what it was intended to mean, and it seems like you are sweeping that
under the rug.  The question is not just what the right transform is,
but how to deal with what ought to be now, under the assumption things
were wrong before.

I agree that c++17 in USE_LANGUAGES used to have the effect of forcing
std via the wrappers, and that if the program itself sets the --std
flags for what it needs, then it can be removed from USE_LANGUAGES.

However, if kicad actually needs to compile c++17, then this should be
in USE_CXX_FEATURES, because otherwise it might be compiled with a
compiler that lacks this.

It would be great if someone added a way to insert --std=c++03 and drop
all higher std from the wrappers, if no c++NN were in USE_CXX_FEATURES.
Just because kicad compiles on some system doesn't mean it's ok -- if
the compiler in use will support c++17, then undeclared c++17 use will
go undetected.

This is not a regression and not a complaint about the change.  The
point is that when going over things, we should ask "is it right now"
more broadly.