Add toolchain cb3 compilers

[isuruf]

cc @msarahan

[conda-forge-linter]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[isuruf]

@conda-forge-admin, please rerender.

[conda-forge-linter]

Hi! This is the friendly automated conda-forge-linting service.

I wanted to let you know that I linted all conda-recipes in your PR (recipe) and found some lint.

Here's what I've got...

For recipe:

• The recipe must have some tests.

[msarahan]

This looks good to me. I simplified it a few ways, but the general concepts are all correct.

[jakirkham]

So we currently don't ship these things as we have been using system libraries. Guess we could start doing that with Linux and that would probably help some people who have been wanting this functionality. As we use devtoolset-2, all code is compatible with 4.4+. The LLVM version is based off of 3.6. So would assume the libcxx version matches, but am having trouble finding conformation. Given there are some symbols removed in 4.0, we might want to be a little more cautious here.

ref: https://abi-laboratory.pro/tracker/compat_report/libcxx/3.9.1/4.0.0/54f71/abi_compat_report.html

[jakirkham]

Maybe @mingwandroid can tell me that I'm being too paranoid here. ;)

[jakirkham]

Should we consider this for Linux as well? Personally am of two minds about it. Some low-level packages like scipy avoid the gcc package to avoid some very old issues we use to have regarding the compiler runtime not always being shipped. While the rest of the stack has no problem using gcc for Fortran on either platform.

[isuruf]

If we don't add this for Linux, we should install gfortran in the docker image. I didn't want to install gcc because I remember issues about gcc not working sometimes due to bugs in it. Shall I send a PR to install gfortran in docker image? or add gcc for Linux here?

[jakirkham]

Yeah adding gfortran to the docker image seems like the least troublesome option. Let's go with that. It shouldn't affect anyone using the gcc package with libgcc already as those will take priority. Also with this change to toolchain anyone using the docker-image gfortran will just get the run time libraries added.

[jakirkham]

So what happens if we merge this and someone installs toolchain as is (i.e. as a build requirement)?

Also what happens on the Windows front given we add a no-op Windows compiler? Does that override, supplements, something else to what defaults provides? If it supplements, what would the order be?

[isuruf]

So what happens if we merge this and someone installs toolchain as is (i.e. as a build requirement)?

No change

Also what happens on the Windows front given we add a no-op Windows compiler? Does that override, supplements, something else to what defaults provides? If it supplements, what would the order be?

We are not adding a no-op windows compiler. We'd be using,

c_compiler:
  - vs2008                     # [win]
  - vs2015                     # [win]
  - vs2015                     # [win]
  - toolchain_c               # [unix]

So {{ compiler('c') }} would expand to toolchain_c_linux-64 (which is from this PR) for linux and vs2008_win-64 (which is from defaults) for windows.

[isuruf]

See conda-forge/conda-forge-pinning-feedstock#48 for how this would be used.

[jakirkham]

Thanks @isuruf.

[jakirkham]

Guess the next step is to start educating people about this change by updating examples and docs.

[mingwandroid]

Can anyone give me a high level overview of what's going on here?

[isuruf]

{{ compiler('c') }} is expanded to toolchain_c which is just toolchain + libgcc.

This is done so that we can merge AnacondaRecipes recipes back to conda-forge. To use the new compilers we only have to change conda_build_config.yaml, which we will do once all the packages are rebuilt. This was @msarahan's idea. He can give you more details.

[mbargull]

Should this use

        - libcxx >=???  # [osx]

?