[sr #110286] Make it possible to request a specific (non-latest) version of a language standard

[Zack Weinberg]

Update of sr#110286 (group autoconf):

Severity:1 - Wish => 4 - Important  
  Status:None => Confirmed  

___

Follow-up Comment #2:

Because we have reports that automatic selection of the latest language
standard actually breaks various builds (e.g. bug #110879), let's treat this
as an actual bug rather than just a feature request, and as a priority for
2.73.  It is too late to do anything about it for 2.72, however.

Copying over links posted in bug #110879:

* 
* 
* 
* 
*



___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #110286] Make it possible to request a specific (non-latest) version of a language standard

[Zack Weinberg]

Update of sr#110286 (group autoconf):

Priority: 1 - Blocked => 3 - Release N+1


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #110286] Make it possible to request a specific (non-latest) version of a language standard

[Zack Weinberg]

Update of sr #110286 (project autoconf):

Priority:  5 - Normal => 1 - Later  

___

Follow-up Comment #1:

I don't think it's going to be possible to make this happen before 2.70.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

Re: [sr #110286] Make it possible to request a specific (non-latest) version of a language standard

[Dima Pasechnik]

On Mon, Jul 27, 2020 at 02:31:38PM -0400, Zack Weinberg wrote:
> URL:
>   
> 
>  Summary: Make it possible to request a specific (non-latest)
> version of a language standard
>  Project: Autoconf
> Submitted by: zackw
> Submitted on: Mon 27 Jul 2020 06:31:37 PM UTC
> Category: None
> Priority: 5 - Normal
> Severity: 1 - Wish
>   Status: None
>  Privacy: Public
>  Assigned to: None
> Originator Email: 
>  Open/Closed: Open
>  Discussion Lock: Any
> Operating System: None
> 
> ___
> 
> Details:
> 
> Feedback on the 2.69b beta indicates that users find the new behavior of
> AC_PROG_CC and AC_PROG_CXX, automatically selecting the latest supported
> language standard, problematic.  Quoting
> https://lists.gnu.org/archive/html/autoconf/2020-07/msg00010.html :
> 
> > One issue we [PostgreSQL] would like to point out is that
> > the new scheme of automatically checking for the latest
> > version of the C and C++ standards (deprecating AC_PROG_CC_C99
> > etc.) is problematic...
> > 
> > [W]e have set C99 as the project standard. So checking for
> > C11 is (a) useless, and (b) bad because we don't want
> > developers to accidentally make use of C11 features and have
> > the compiler accept them silently.
> >
> > It looks like it's not easy to disable these tests even
> > with low-level hackery. It would be better if there were
> > still a way to set the preferred level of C and C++ in
> > an official way.
> 
> and https://lists.gnu.org/archive/html/autoconf/2020-07/msg00012.html :
> 
> > Particularly as applies to C++, it is useful to be able
> > to set an upper bar (and lower bar) for the C++ version
> > requested because C++11 is in many ways not similar to
> > older C++. I am already aware that some of my own software
> > will not compile with C++11 because of removed deprecated
> > features which I have not attended to yet in the code.
> > Furthermore, the ABI often changes between C++ versions
> > and it is useful to be able to specify the C++ version
> > for purposes of the ABI.

In regard of C++, we (in SageMath, https://sagemath.org) are using 
AX_CXX_COMPILE_STDCXX from
 https://www.gnu.org/software/autoconf-archive/ax_cxx_compile_stdcxx.html
to do version detection of C++.

Perhaps it can be promoted to the core AC_ macros.

Just in case,
Dmitrii
> 
> ___
> 
> Reply to this item at:
> 
>   
> 
> ___
>   Message sent via Savannah
>   https://savannah.gnu.org/
> 
> 


signature.asc
Description: PGP signature

Re: [sr #110286] Make it possible to request a specific (non-latest) version of a language standard

[Nick Bowler]

On 2020-07-27, Zack Weinberg  wrote:
> URL:
>   
>
>  Summary: Make it possible to request a specific
> (non-latest)
> version of a language standard
>  Project: Autoconf
> Submitted by: zackw
> Submitted on: Mon 27 Jul 2020 06:31:37 PM UTC
> Category: None
> Priority: 5 - Normal
> Severity: 1 - Wish
>   Status: None
>  Privacy: Public
>  Assigned to: None
> Originator Email:
>  Open/Closed: Open
>  Discussion Lock: Any
> Operating System: None
>
> ___
>
> Details:
>
> Feedback on the 2.69b beta indicates that users find the new behavior of
> AC_PROG_CC and AC_PROG_CXX, automatically selecting the latest supported
> language standard, problematic.  Quoting
> https://lists.gnu.org/archive/html/autoconf/2020-07/msg00010.html :
>
>> One issue we [PostgreSQL] would like to point out is that
>> the new scheme of automatically checking for the latest
>> version of the C and C++ standards (deprecating AC_PROG_CC_C99
>> etc.) is problematic...
>>
>> [W]e have set C99 as the project standard. So checking for
>> C11 is (a) useless, and (b) bad because we don't want
>> developers to accidentally make use of C11 features and have
>> the compiler accept them silently.

I have no comments on the C++ side of things but on the C side this
request doesn't make too much sense.

As a portability tool, the goal of Autoconf and configure scripts is
to find a compiler that can successfully compile the application.

Aside from the removal of gets from the standard library (which most
C11 compilers still implement anyway) and that some language features
which were mandatory in C99 are now optional (which again, most C11
compilers implement anyway), C11 is essentially completely backwards
compatible with C99 so such a compiler should be perfectly fine for
building a C99 codebase.

AC_PROG_CC_C99 has never guaranteed that a C99 compiler will be selected,
it is "best effort" only and has always accepted C11 compilers provided
they support VLAs.  GCC has defaulted to C11 mode for the better part
of a decade now (since version 5) and AC_PROC_CC_C99 will not add any
options.

All compilers I'm aware of that support both C99 and C11 modes will
silently accept most if not all C11 features even when C99 mode is
selected by the user.  So having Autoconf select a C99 mode is probably
not going to do anything to help projects avoid modern language
features.  For the same reason it could be difficult to write a feature
test program which usefully determines that the compiler is in C99 mode
(probably the best you can do is test for specific values of the
__STDC_VERSION__ macro which is really not the Autoconf way).

If you don't want specific language constructs to be used in your
codebase the proper way to do this is with linting tools or warning
flags during development, not with portability tools like Autoconf.

For example with GCC if you want to reject new C11 syntax you can
build with the -Werror=c99-c11-compat option.  (You could even use
Autoconf to write a configure test that will automatically add this
option to CFLAGS if it is supported by the compiler.

Cheers,
  Nick

[sr #110286] Make it possible to request a specific (non-latest) version of a language standard

[Zack Weinberg]

URL:
  

 Summary: Make it possible to request a specific (non-latest)
version of a language standard
 Project: Autoconf
Submitted by: zackw
Submitted on: Mon 27 Jul 2020 06:31:37 PM UTC
Category: None
Priority: 5 - Normal
Severity: 1 - Wish
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
Operating System: None

___

Details:

Feedback on the 2.69b beta indicates that users find the new behavior of
AC_PROG_CC and AC_PROG_CXX, automatically selecting the latest supported
language standard, problematic.  Quoting
https://lists.gnu.org/archive/html/autoconf/2020-07/msg00010.html :

> One issue we [PostgreSQL] would like to point out is that
> the new scheme of automatically checking for the latest
> version of the C and C++ standards (deprecating AC_PROG_CC_C99
> etc.) is problematic...
> 
> [W]e have set C99 as the project standard. So checking for
> C11 is (a) useless, and (b) bad because we don't want
> developers to accidentally make use of C11 features and have
> the compiler accept them silently.
>
> It looks like it's not easy to disable these tests even
> with low-level hackery. It would be better if there were
> still a way to set the preferred level of C and C++ in
> an official way.

and https://lists.gnu.org/archive/html/autoconf/2020-07/msg00012.html :

> Particularly as applies to C++, it is useful to be able
> to set an upper bar (and lower bar) for the C++ version
> requested because C++11 is in many ways not similar to
> older C++. I am already aware that some of my own software
> will not compile with C++11 because of removed deprecated
> features which I have not attended to yet in the code.
> Furthermore, the ABI often changes between C++ versions
> and it is useful to be able to specify the C++ version
> for purposes of the ABI.







___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/