Harmonize symlinks structure between platforms

[h-vetinari]

In #113, we needed to make some modifications to account for conda-forge/clangdev-feedstock#251, which placed some symlinks that used to be done in this feedstock into another output (for good reason). Now however we have a situation where these things are not consistent between versions (kinda OK, eventually the old ones drop off), and more importantly, between platforms.

There was some discussion about how to deal with it, and we agreed that things should be harmonized if possible. I came up with the following table:

output	linux-*	osx-*
gcc_impl_ $target_platform	bin/x86_64-conda-linux-gnu-cc... bin/x86_64-conda_cos6-linux-gnu-cc...	-
gcc_ $target_platform	.../activate-gcc_linux-64.sh .../deactivate-gcc_linux-64.sh	-
gcc	bin/gcc	-
clang_impl_ $target_platform	-	bin/x86_64-apple-darwin13.4.0-clang or bin/arm64-apple-darwin20.0.0-clang
clang_ $target_platform	-	.../activate_clang_osx-64.sh .../deactivate_clang_osx-64.sh
clang	bin/clang bin/x86_64-conda-linux-gnu-clang	bin/clang

I noted:

Perhaps the cleaner approach [than having bin/x86_64-conda-linux-gnu-clang in clang] would be to create an activation feedstock for clang on linux (or do it in this one?) and then have bin/x86_64-conda-linux-gnu-clang be under clang_impl_linux-64?

In that way, this issue is quite closely related to #117.

Summarizing how a potential future setup might look like:

output	linux-*	osx-*
gcc_impl_ $target_platform	bin/x86_64-conda-linux-gnu-cc... bin/x86_64-conda_cos6-linux-gnu-cc...	-
gcc_ $target_platform	.../activate-gcc_linux-64.sh .../deactivate-gcc_linux-64.sh	-
gcc	bin/gcc	-
clang_impl_ $target_platform	bin/x86_64-conda-linux-gnu-clang	bin/x86_64-apple-darwin13.4.0-clang or bin/arm64-apple-darwin20.0.0-clang
clang_ $target_platform	.../activate_clang_linux-64.sh .../deactivate_clang_linux-64.sh	.../activate_clang_osx-64.sh .../deactivate_clang_osx-64.sh
clang	bin/clang	bin/clang

[h-vetinari]

One thing that would need to happen to achieve consistency between linux & osx (i.e. have clang contain $PREFIX/bin/clang and the activation) is that we'd have to rename the outputs in clangdev.

For linux we're building (in order of dependence):

• {gcc,gxx}_impl_$target_platform on https://github.com/conda-forge/ctng-compilers-feedstock
• {gcc,gxx}_$target_platform on https://github.com/conda-forge/ctng-compiler-activation-feedstock
• {gcc,gxx} on https://github.com/conda-forge/ctng-compiler-activation-feedstock

For clang, we'd need one more stage I think:

• clang{,xx}_base (or simply the existing clang-{{ major }}) on https://github.com/conda-forge/clangdev-feedstock
• clang{,xx}_impl_$target_platform on https://github.com/conda-forge/ctng-compilers-feedstock (linux) resp. here (osx)
• clang{,xx}_$target_platform on https://github.com/conda-forge/ctng-compilers-feedstock (linux) resp. here (osx)
• clang{,xx} on https://github.com/conda-forge/ctng-compilers-feedstock (linux) resp. here (osx)

[isuruf]

gcc, gxx should go into https://github.com/conda-forge/ctng-compilers-feedstock and that's it. There's no other change necessary IMO.

[h-vetinari]

gcc, gxx should go into https://github.com/conda-forge/ctng-compilers-feedstock and that's it.

IIUC, you're suggesting to make gcc be an output without compiler-activation by default? That'd be nice as well, in the sense that the only activated compilers are then the {gcc,gxx,clang,clangxx}_<target> outputs.

[isuruf]

IIUC, you're suggesting to make gcc be an output without compiler-activation by default?

gcc does not do activation already.