mainAutoconf - Support: sr #110286, Make it possible to request a...

 
 

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

Submitter:  Zack Weinberg <zackw>
Submitted:  Mon 27 Jul 2020 06:31:37 PM UTC
Votes: 1
 
Priority:  * 3 - Release N+1 Severity:  4 - Important
Status:  Confirmed Privacy:  Public
Assigned to:  None Open/Closed:  Open
Operating System:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Thu 17 Oct 2024 06:47:44 AM UTC, comment #6: 


comment #5:

> As far as I know the original bug (#110879, which led to the Ixion issue for example) has been fixed in bleeding-edge Autoconf on Savannah.


Ah that's great. I did not monitor Autoconf commit history (as I would not understand most things in there anyway).
Looks like <https://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=056518b94ecd487bcbefdb69046b3f52c4168222> should solve #110879. Thank you for that.

> However, nobody has yet volunteered to implement the feature request "Make it possible to request a specific version of a language standard". If you can volunteer or find a volunteer, please do so.


Well, it's still somewhat questionable whether anything needs to be done at all for C++. autoconf-archive ax_cxx_compile_stdcxx.m4 exists and has been used for this since ages. I strongly suggest that, if anything would be implemented, it should consider some kind of forward/backward compatibility with ax_cxx_compile_stdcxx.m4.

The C situation is a little bit different and more convoluted with AC_PROG_CC, AC_PROG_CC_STDC, and AC_PROG_CC_C99, as far as I can tell.

> I suppose we could generate a new Autoconf version now, to fix this bug in a release, and implement the feature request later.


That sounds like a good idea, as the previous situation obviously has caused some trouble for multiple projects.

Jörn Heusipp <manx>
Thu 17 Oct 2024 06:05:35 AM UTC, comment #5: 

As far as I know the original bug (#110879, which led to the Ixion issue for example) has been fixed in bleeding-edge Autoconf on Savannah.

However, nobody has yet volunteered to implement the feature request "Make it possible to request a specific version of a language standard". If you can volunteer or find a volunteer, please do so.

I suppose we could generate a new Autoconf version now, to fix this bug in a release, and implement the feature request later.

Paul Eggert <eggert>
Group administrator
Thu 17 Oct 2024 02:48:51 AM UTC, comment #4: 

This led to this issue with Ixion, for reference:
https://gitlab.com/ixion/ixion/-/issues/64

Eric Gallager <egallager>
Wed 16 Oct 2024 12:23:02 PM UTC, comment #3: 

Still no fix?

Jörn Heusipp <manx>
Fri 08 Dec 2023 05:14:34 PM UTC, 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:

Zack Weinberg <zackw>
Group administrator
Sun 15 Nov 2020 08:24:17 PM UTC, comment #1: 

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

Zack Weinberg <zackw>
Group administrator
Mon 27 Jul 2020 06:31:37 PM UTC, original submission:  

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.




Zack Weinberg <zackw>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by eggert (Posted a comment)
  • -email is unavailable- added by egallager (Posted a comment)
  • -email is unavailable- added by manx (Posted a comment)
  • -email is unavailable- added by egallager (Voted in favor of this item)
  • -email is unavailable- added by zackw
  • -email is unavailable- added by zackw (Submitted the item)
  •  

    There is 1 vote so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2024-05-10 egallager Carbon-Copy- Added egallager
    2023-12-08 zackw Severity1 - Wish 4 - Important
        StatusNone Confirmed
    2023-12-08 zackw Priority1 - Blocked 3 - Release N+1
    2020-12-09 zackw Carbon-Copy- Added karl
    2020-11-15 zackw Priority5 - Unprioritized 1 - Blocked

    Back to the top

    Powered by Savane 3.14-9aa3.
    Corresponding source code