On Tue, 3 Sept 2024 at 10:51, Jonathan Wakely <jwak...@redhat.com> wrote: > > On Fri, 23 Aug 2024 at 22:57, Andrew Pennebaker via austin-group-l at > The Open Group <austin-group-l@opengroup.org> wrote: > > > > Hi, > > > > I am interested in learning more about the default implicit rules. It seems > > that make has explicitly supported C projects for many years, providing > > default rule behaviors for common C files, including implementation files, > > header files, objects, and executables. > > > > Given the popularity of the higher level C++ language, I think it would be > > useful to declare similar implicit default rules for C++ project files. > > > > As of POSIX 2024, make defaults the C standard version to C17. Simply for > > parity, propose declaring the default C++ standard version as C++17. > > When POSIX 2024 was published, C17 was the most recent standard. > Whereas C++23 is already complete (although not actually published by > ISO yet) and by the time there's a new POSIX standard, we'll have had > at least one new C++ standard, probably more. Pinning POSIX to C++17 > in 2024 probably makes sense (neither GCC nor Clang claims full > support of C++20 yet) but will be anachronistic by the time a new > POSIX standard is published. It might make sense for now though, and > if this proposal went forward it could be updated later. > > > > > The default C++ compiler program name would be "c++". > > Currently GCC installs "c++" as a hard link for the "g++" binary, > which defaults to -std=gnu++17 (as of GCC 11, released three years > ago). > > It sounds like this proposal would mean that the "c++" executable > would need to behave like "g++ -std=c++17" instead, which would be a > change from what happens today. It would also mean that when g++ > changes its default to -std=gnu++20 at some point in the nearish > future, the c++ executable would diverge further from the g++ one. > Wouldn't it make more sense to propose something akin to the c99 > executable to specify a C++ compiler with a particular set of > defaults, such as C++17 dialect, e.g. a c++17 or cxx17 executable? > > > > > In addition to C's CFLAGS, we have: > > > > * CPPFLAGS (apply to both C and C++ implementation and header files) > > * CXXFLAGS (apply solely to C++ implementation and header files) > > > > We have an opportunity to improve the out of the box compilation behavior > > for C++ projects with make. Unlike C, many C++ compilers fall on their face > > if the C++ standard library version is not set. > > I'm not sure what this sentence means. -std does not set "the C++ > standard library version" (it also sets the core language version, > i.e. which syntax and keywords are supported) and nothing falls on its > face without that (because there's a default value for -std which is > always there implicitly). > > > Conventionally -std=c++17. > > That's the option that GCC uses, and Clang adopted too (since one of > Clang's original goals was to be a drop-in replacement for GCC). It's > also used by Intel compilers on POSIX when they're aiming for > compatibility with a system compiler that is GCC or Clang. I'm not > sure if it's a convention that extends further than that. I don't > think that option was valid for Sun compilers, nor IBM xlC (although > maybe it is for the new LLVM-based xlC compilers).
A new "cxx17" (or "c++17" or "cxc17" or whatever) executable would side step any concerns about whether -std is a valid option for the system's C++ compiler. Instead of defaulting to $(CXX) -std=c++17, which might not even be a valid option for the CXX compiler, a specific cxx17 executable would just do whatever is needed to invoke the $(CXX) compiler with the right options to select C++17. No -std option in sight, and so no concerns about whether that option works or not. > > > We could feature -std=$(C++17) as one of the default CXXFLAGS entries, so > > that more C++ programs build correctly by default. > > Since current versions of GCC and Clang both default to C++17 mode > anyway, why would you want to explicitly override that with a default > value of CXXFLAGS? That would be a breaking change for many C++ > programs which currently rely on the default (because -std=c++17 is > not the same as -std=gnu++17). > > > Anyone who wishes to override this behavior may customize CXXFLAGS. So > > embedded developers, C++23 developers, and legacy C++11 or older developers > > can continue with minimal impact. > > If you don't add a -std option to CXXFLAGS, then there's even less impact. > > > autotools, cmake, ninja, and a dozen other build systems also support C++ > > projects. But ideally we tap into the elegance of pure make. > > > > Same question for linkers (ld program, .ld files), and for assemblers as > > well (cc program, .asm files). > > > > I think it's an interesting historical quirk that make has built-in rules > > for lex and yacc but not C++. > > > > -- > > Cheers, > > Andrew
