[prev in list] [next in list] [prev in thread] [next in thread]
List: cmake
Subject: Re: [CMake] C++ standard version fallbacks.
From: Craig Scott <craig.scott () crascit ! com>
Date: 2017-06-06 13:18:16
Message-ID: CA+dygYm5NnHc7toJOJ051CJ46H20-vpaYxOz1j_B7P0HQv-enw () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Tue, Jun 6, 2017 at 8:50 AM, Stephen Kelly <steveire@gmail.com> wrote:
> Craig Scott wrote:
>
> > On Tue, Jun 6, 2017 at 7:50 AM, Stephen Kelly
> > <steveire@gmail.com> wrote:
> >
> >> Roger Leigh wrote:
> >>
> >> > Hi folks,
> >> >
> >> > I'm currently using this logic to use C++14 with a fallback to C++11
> >> > when C++14 is unavailable:
> >> >
> >> > if(NOT CMAKE_CXX_STANDARD)
> >> > set(CMAKE_CXX_STANDARD 14)
> >> > endif()
> >> > if(NOT CMAKE_CXX_STANDARD_REQUIRED)
> >> > set(CMAKE_CXX_STANDARD_REQUIRED 11)
> >> > endif()
> >> >
> >> > which seems to work OK.
> >> >
> >> > However, for some new stuff, I'd like to use C++17 when available, but
> >> > fall back to C++14, C++11 or C++98. Is it possible to do this?
> >>
> >> Probably set CMAKE_CXX_STANDARD
> >>
> >> without CMAKE_CXX_STANDARD_REQUIRED (That variable doesn't really make
> >> sense
> >> to me and I think it is overused when not needed).
> >>
> >
> > If you don't set CMAKE_CXX_STANDARD_REQUIRED, then there's no guarantee
> > you get any particular minimum standard.
>
> He wants to fall back all the way to C++98. Am I missing something?
>
Sorry, my comments were based on the example code which looks as though it
was expecting C++11 to be a minimum requirement. The paragraph that follows
it describes a different scenario, as you say. Apologies for the confusion!
>
> > Roger's example (sorry Roger!)
> > highlights part of the confusion about this latter variable (and the
> > target property it ultimately controls). He appears to be setting it
> > expecting it to specify a minimum version, but that's not how it works.
> It
> > is expected to be a boolean which says whether CMAKE_CXX_STANDARD must be
> > honoured or not, which most developers (myself included) tend to find
> > unintuitive.
>
> Ok.
>
> I remember I was opposed to introducing CMAKE_CXX_STANDARD_REQUIRED in the
> first place as I think it is redundant. I recommend populating compile
> features for whatever you absolutely need and let cmake populate the std
> flag. If your code can benefit from a more-recent std flag than the
> requirement, then set CMAKE_CXX_STANDARD to that.
>
> > Roger's use would actually make it a bit better, if that was
> > how it worked, but unfortunately there's currently no way to set a
> > *minimum* standard version,
>
> If you have a minimum, then you must be relying on some language features
> existing and you can list those.
>
Until very recently, that only worked for language features, it didn't help
if you relied on parts of the STL, for example. I think the recently added
cxx_std_?? compiler meta feature comes close to giving the behaviour I was
describing now, but it is less convenient in that you always have to set it
for every target, there isn't an associated variable that sets a default
for all targets (that I'm aware of - I'd be happy to be wrong on this one!).
Roger, to get back to your original question, Stephen's suggestion of not
setting CMAKE_CXX_STANDARD_REQUIRED is probably going to give you what you
are seeking. My view is that setting just CMAKE_CXX_STANDARD leads to
unintuitive behaviour for many developers, but since you've explicitly
stated that it is indeed the behaviour that you want, then I guess it works
for you. Just be prepared to explain it to other developers from time to
time!
[Attachment #5 (text/html)]
<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun \
6, 2017 at 8:50 AM, Stephen Kelly <span dir="ltr"><<a \
href="mailto:steveire@gmail.com" target="_blank">steveire@gmail.com</a>></span> \
wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex"><span class="">Craig Scott wrote:<br> <br>
> On Tue, Jun 6, 2017 at 7:50 AM, Stephen Kelly<br>
> <<a href="mailto:steveire@gmail.com">steveire@gmail.com</a>> wrote:<br>
><br>
>> Roger Leigh wrote:<br>
>><br>
>> > Hi folks,<br>
>> ><br>
>> > I'm currently using this logic to use C++14 with a fallback to \
C++11<br> >> > when C++14 is unavailable:<br>
>> ><br>
>> > if(NOT CMAKE_CXX_STANDARD)<br>
>> > set(CMAKE_CXX_STANDARD 14)<br>
>> > endif()<br>
>> > if(NOT CMAKE_CXX_STANDARD_REQUIRED)<br>
>> > set(CMAKE_CXX_STANDARD_<wbr>REQUIRED 11)<br>
>> > endif()<br>
>> ><br>
>> > which seems to work OK.<br>
>> ><br>
>> > However, for some new stuff, I'd like to use C++17 when available, \
but<br> >> > fall back to C++14, C++11 or C++98. Is it possible to do \
this?<br> >><br>
>> Probably set CMAKE_CXX_STANDARD<br>
>><br>
>> without CMAKE_CXX_STANDARD_REQUIRED (That variable doesn't really \
make<br> >> sense<br>
>> to me and I think it is overused when not needed).<br>
>><br>
><br>
> If you don't set CMAKE_CXX_STANDARD_REQUIRED, then there's no \
guarantee<br> > you get any particular minimum standard.<br>
<br>
</span>He wants to fall back all the way to C++98. Am I missing \
something?<br></blockquote><div><br></div><div>Sorry, my comments were based on the \
example code which looks as though it was expecting C++11 to be a minimum \
requirement. The paragraph that follows it describes a different scenario, as you \
say. Apologies for the confusion!</div><div><br></div><div> </div><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> <span class=""><br>
> Roger's example (sorry Roger!)<br>
> highlights part of the confusion about this latter variable (and the<br>
> target property it ultimately controls). He appears to be setting it<br>
> expecting it to specify a minimum version, but that's not how it works. \
It<br> > is expected to be a boolean which says whether CMAKE_CXX_STANDARD must \
be<br> > honoured or not, which most developers (myself included) tend to find<br>
> unintuitive.<br>
<br>
</span>Ok.<br>
<br>
I remember I was opposed to introducing CMAKE_CXX_STANDARD_REQUIRED in the<br>
first place as I think it is redundant. I recommend populating compile<br>
features for whatever you absolutely need and let cmake populate the std<br>
flag. If your code can benefit from a more-recent std flag than the<br>
requirement, then set CMAKE_CXX_STANDARD to that.<br>
<span class=""><br>
> Roger's use would actually make it a bit better, if that was<br>
> how it worked, but unfortunately there's currently no way to set a<br>
</span>> *minimum* standard version,<br>
<br>
If you have a minimum, then you must be relying on some language features<br>
existing and you can list those.<br>
<div class="HOEnZb"><div class="h5"></div></div></blockquote></div><div \
class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div \
dir="ltr"><div><div dir="ltr"><div><br></div><div><font color="#500050">Until very \
recently, that only worked for language features, it didn't help if you relied on \
parts of the STL, for example. I think the recently added cxx_std_?? compiler meta \
feature comes close to giving the behaviour I was describing now, but it is less \
convenient in that you always have to set it for every target, there isn't an \
associated variable that sets a default for all targets (that I'm aware of - \
I'd be happy to be wrong on this one!).</font></div><div><font \
color="#500050"><br></font></div><div><font color="#500050">Roger, to get back to \
your original question, Stephen's suggestion of not setting \
CMAKE_CXX_STANDARD_REQUIRED is probably going to give you what you are seeking. My \
view is that setting just CMAKE_CXX_STANDARD leads to unintuitive behaviour for many \
developers, but since you've explicitly stated that it is indeed the behaviour \
that you want, then I guess it works for you. Just be prepared to explain it to other \
developers from time to time!</font></div><div><font \
color="#500050"><br></font></div><div><font \
color="#500050"><br></font></div></div></div></div></div></div></div> </div></div>
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at: \
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more information \
on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at \
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic