conda-build should not set std=c++17 by default

[looooo]

encountered here:
conda-forge/boost-cpp-feedstock#43

problem: boost is build with -std=c++17. But the boost-depending library is not yet working with c++17 standard. Therefor building with c++14. But afterwards runtime-errors occur due to missing symbols (symbols would be available if boost is build with same c++-standard or lower.) So theoretically a lower c++-standart gives a more compatible library. Therefor I guess it's best to set the default c++-standart to c++11 or lower.

conda-build/tests/test-recipes/metadata/_run_exports_in_outputs/conda_build_config.yaml

Line 46 in 7dac1cb

- -fvisibility-inlines-hidden -std=c++17 -fmessage-length=0 -march=nocona -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-strong -fno-plt -O2 -pipe

[msarahan]

conda-build does not set any of this. It is done in the compiler activation scripts: https://github.com/AnacondaRecipes/aggregate/blob/master/ctng-compilers-activation-feedstock/recipe/conda_build_config.cos6.x86_64.yaml

@mingwandroid can explain more, but I don't think we're going to change that. That setting has been in place for nearly 2 years now, so there's definitely ways to make things work.

[looooo]

For conda-forge this setting was introduced with the compiler update happening in the last year (forcing us to use new-compilers since beginning of this year).

@mingwandroid can explain more, but I don't think we're going to change that. That setting has been in place for nearly 2 years now, so there's definitely ways to make things work.

Yes we have to rebuild boost and deps... This would have been avoided if an older c++-standard was used by default.

Can you explain why c++17 was chosen?

[mingwandroid]

We aren't interested in this, sorry. There are no compat issues with C++ standards so long as you use a modern compiler. We provide that.

C++17 was picked because it's the most modern version our compilers support.

[mingwandroid]

If c++17 is too modern for a given package then build.sh should mask that value away. This has been discussed many times before.

We want the most simple C++ package (e.g. one using the most basic Makefile possible) to be able to detect and use c++17 to take advantage of such things as move semantics in order to generate the fastest code possible.

[mingwandroid]

problem: boost is build with -std=c++17. But the boost-depending library is not yet working with c++17 standard. Therefor building with c++14

The changes from c++14 to c++17 are minor, I suggest you apply a patch to remove dynamic exception specification used in LaughlinResearch/SMESH

[looooo]

If c++17 is too modern for a given package then build.sh should mask that value away. This has been discussed many times before.

This won't work for (some) packages depending on boost.

I understand that you want to stay with c++17 by default, but for boost and maybe other libraries using c++17 makes no sense as this only increase the incompatibilities.

[mingwandroid]

I understand that you want to stay with c++17 by default, but for boost and maybe other libraries using c++17 makes no sense as this only increase the incompatibilities

This is not the case. To be clear, project A could contain:

#if __cplusplus < 20110210
int some_symbol_a;
#endif

While some project B could contain:

#if __cplusplus >= 20110210
int some_symbol_b;
#endif

.. and there is no setting for -std= that will allow both symbols to be defined. In other words it has nothing to do with the decision about which standard is selected.

Also, pessimissing (i.e. making it slower) a library which is as low-level and important as Boost because some other project hasn't modernised (esp. when it's as simple as it is in the case of LaughlinResearch/SMESH) is not something we should entertain IMHO. Where does this end? If there was a project which uses Boost but also requires C++98, would you propose trying to build Boost in C++98 mode?

This is a case of "throwing the baby out with the bathwater"!

[looooo]

Boost was build with c++98 for good old conda with toolchain. Also arch Linux uses c++14. Jumping to c++17 is a huge step.

Yes it's maybe easy solveable for smesh. But the next library I fear about is freecad. This library doesn't yet work with c++14. So maybe I am lucky and everything works with c++11. We will see.

This is not the case. To be clear, project A could contain:

Ok so we would have the same problem if boost was build with c++11 and smesh with c++17.
But then please don't give the suggestion to set the standart in the build.sh. it may works, but in some cases it won't work.

In the end, yes it's good if you aim for consistency.

[mingwandroid]

But then please don't give the suggestion to set the standart in the build.sh.

This is frequently exactly what needs to be done. We've done this for 1.5 years now.

[github-actions]

Hi there, thank you for your contribution!

This issue has been automatically locked because it has not had recent activity after being closed.

Please open a new issue if needed.

Thanks!