Closed minrk closed 5 years ago
In particular, setting the -std flag seems like an unexpected default behavior for a compiler, to me
Why do you say that? The language is largely backwards compatible and always has been.
Yes I have set them on purpose so that software without complex build systems will take advantage of it without any effort on their part beyond:
#if __cplusplus >= 201703L
.. use some C++17
#else
.. use some C++98
#endif
.. if c++17 causes an issue then mask that flag out in your build.sh
. I intend, unless someone can come up with a good reason not to, to keep this flag updated to the latest available C++ standard that the compiler fully supports, until such a time as the C++ grammar is changed in an incompatible way.
if c++17 causes an issue then mask that flag out in your build.sh
I did mask it out, and it was indeed the cause of the build failures.
Why do you say that?
It seems odd to me to switch an opt-in feature to an opt-out feature when there's apparently little to no benefit in doing so, and opting out involves sed while opting in is simple.
until such a time as the C++ grammar is changed in an incompatible way.
I guess C++17 is one such event, then.
The issue is that the benefits are silently lost if you require opting in and I don't want to lose those.
Since ctng-compilers inherit
@CXXFLAGS
apparently from build-time of the recipe, activating these compilers sets a lot of flags by default:In particular, setting the
-std
flag seems like an unexpected default behavior for a compiler, to me. Are all of these flags set on purpose, and is there a negative consequence to setting any of these by default? I'm debugging a build issue on nodejs right now, and my first hunch is that it may have to do with the fact that it has two flags for-std
:-std=c++17 -std=gnu++1y
.