Re: dealing with inevitable warnings from new compilers on old code

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

"Greg A. Woods" <woods%planix.ca@localhost> writes:

> So it is actually telling us to use FORCE_C_STD to set the desired
> language level when necessary.

Yes, to work around buggy packages that do not.

> As I said, USE_CC_FEATURES has an _opposite_ purpose to the present need
> to _lower_ the language level and so it is clearly useless for this
> purpose.  Besides it currently only sets the minium compiler for GCC,
> and it doesn't affect any other compiler than GCC, nor does it set
> "-std=".

It is not opposite; it is different.  It intends to require a compiler
capable of what has been asked for, and in theory that is a set, and in
theory would be implemented for compilers.  It does not set --std; that
should be done by the package.  And, a package might build some files
with c++11 and some with c++17.  Yes, that's deviant.

>> FORCE_{C,CXX}_STD adds --std=foo via the wrappers.  As I read the
>> documentation and the code, this is independent of requiring a compiler
>> that needs that.  That reading matches my inuition about how this ought
>> to be.  So a C++17 program that fails to set --std=c++17 needs:
>> 
>> USE_LANGUAGES=		c++
>> USE_CXX_FEATURES=	c++17
>> FORCE_CXX_STD=		c++17
>
> I would guess that pkgsrc would not be workable on any platform where
> the default C compiler was an ancient GCC 3.x release, so in general

I am unclear on how far back we can go and cope.

> it's not likely necessary to ever have to combine USE_CC_FEATURES (as it
> is currently implemented) and FORCE_C_STD to downgrade the language
> level, though obviously there isn't any harm in it either, and I guess
> it could be updated to catch out any compiler that had dropped support
> for legacy language levels.

You are assuming that FORCE_{C,CXX} are downgrade.  They are not.  They
are "add what is specified to the command line".  It could be that a
package needs c++17 but does not set --std and has trouble with a
compiler that could support c++17 but is operating in c++11 mode,
because it was developed on a machine where the compiler defaulted to
c++17.

> The example for legacy code would of course be something more like:
>
> 	USE_LANGUAGES=		c
> 	USE_CC_FEAGTURES=	gnu90
> 	FORCE_C_STD=		gnu90
>
>> If a program is written in some particular C language family member (c11
>> say) and it does not probe for --std=c11 at configure time and pass
>> --std=c11 at compile time, then it is buggy.
>
> Sure, but are you going to fix the package, or tweak the pkgsrc Makefile?

I'm going to use FORCE_*_STD.  But it is important to be clear about
what is buggy and what is not.

> After all the package built just fine before newer compilers came out.
> It's not the package's fault for pkgsrc to be trying to use a newer
> compiler than the package's author ever even heard of.

The author wrote to a standard and should always have had configure that
tried to with build --std=foo and then added it.  Your scenario is a
latent bug in the package.

> The only problem is that it doesn't cleanly deal with the issue of a
> platform upgrade forcing a newer compiler that defaults to a newer
> language standard level and which causes errors on previously "clean"
> code.

It deals fine; this is exposing latent package bugs.

> Ideally there could be a (mostly internal) "DEFAULT_C_STD" setting too
> (i.e. not for use in individual package Makefiles), which would be
> automatically chosen based on the current platform's default compiler
> and some overall assessment of the state of legacy code in all packages.

I don't think that's ideal; I think it would cause more trouble than it
is worth.  Adding FORCE_*_STD is not that hard, and it doesn't happen
all that often.

> Perhaps the problem is small enough to just use FORCE_C_STD in those
> packages that blow up with newer compilers, or maybe a DEFAULT_C_STD is
> a better solution (it would be a better long-term solution I think).

I see the problem as small enough to use FORCE_C_STD, and see simpler as
better.

> I suspect the same applies for C++, so wash, rinse, and repeat with
> _CXX_ as well.

It's much messier there.   The language changes are more frequent and we
run into compilers with varying defaults pretty often.