Re: required c++ language standard

Hey everyone,

CMake can be a journey. Also, there's no good source of "how to CMake today". Thus, the Internet might provide help from varying times and different guidelines. Further, later CMake might require you to do things differently.

Currently, I'd expect a project to configure a minimum version (C++17 in our case) but later version should work as well.

Regarding minimum versions. My current approach would be to set these to a version that works with the oldest still supported distro.

I'd consider Ubuntu 20.04 to be the oldest, but in a few days, after 31. May 2025, it'll be Ubuntu 22.04.

I know some distros offer longer support. Usually this comes with some kind of service subscription. 

Thus, for VOLK I'd set the minimum to versions that are still around and older versions may work by changing the minimum checks. Or they may not. It's a hint for contributions on what to expect. 

Also, if you need to lower minimum versions, you need to know what you're doing.

Why this lengthy explanation?

Expect the minimum C version to be bumped soon to give contributors the opportunity to enjoy later language features.

Cheers 

Johannes 

Marcus Müller <mmueller@gnuradio.org> schrieb am Di., 20. Mai 2025, 20:45:

 >Hi Greg,

better a brief reply than a late one:

On 5/19/25 5:09 PM, Greg Troxel wrote:
> It would be nice to have something easily found by a human,

agreed, but on the scale of "someone needs to know about this" and "it would be bad if
documentation goes out of sync with the implementation", setting the C++17 standard is
something that can really be left up to code.

The problem only arises if you **externally** try to force a C++ standard. If you don't do
that, then it just works. And you'll have a hard time finding a pre-C++17 compiler,
anyways, on a modern Linux.

So, I hope you understand that this is kind of low priority.

>  When packaging, I like
> to align the package config files to the upstream documented
> requirements, rather than fiddling until it builds, to make it more
> likely it will be ok on some other system.

Then simply don't try to externally set C++ standard. A C++ CMake project that needs
anything newer than C++03 typically sets that itself.

> In theory I know that, but I couldn't find it in the cmake output.
> (It's also a general bug of cmake to hide build lines by default :-(
> which makes this harder.)

Seriously, I'm afraid this is a target-specific problem :) again, if you don't try to
force your compiler settings on a project in a nonstandard way, it'll just work :)

> How does building gr-osmosdr work?   I don't see that it requires C++17
> (because it's in C++11 itself), but if the compiler isn't in C++17 mode
> it will object to gnuradio's headers.

CMake. When you declare a dependency on another CMake project, that imports the compiler
capabilities needed by the dependency when applicable. This all just works.

>  So I think I need to in our "buildlink" file (that you include when you
> want to link against stomething) for GNU Radio add a setting to force
> c++17 mode.

That sounds like a reinvention of CMake config files and those are already a reinvention
of pkg-config .pc files – both of which GNU Radio exports, because they are well-supported
standards!
Does pkgsrc not support any of these standard mechanism?

 > My cmake output follows, and I don't see about testing if the compiler
supports C++17.

I'm afraid GNU Radio is in no way different to any of the tens of thousand other
CMake-using projects out there; you'll have to deal with that as packager!

Best regards,
Marcus