From edb085512f21cb0449225a316ecc8c91b69154f3 Mon Sep 17 00:00:00 2001 From: jaimergp Date: Wed, 28 Feb 2024 20:33:21 +0100 Subject: [PATCH 1/5] update infrastructure.md/compilers Co-authored-by: h-vetinari --- docs/glossary.md | 2 +- docs/maintainer/infrastructure.md | 122 +++++++++++++++++++++++++++--- 2 files changed, 112 insertions(+), 12 deletions(-) diff --git a/docs/glossary.md b/docs/glossary.md index 5efcc2942e..0f41897e33 100644 --- a/docs/glossary.md +++ b/docs/glossary.md @@ -15,7 +15,7 @@ sidebar_position: 27 ## ABI -**A**pplication **B**inary **I**nterface. ABI is a document that comprehensively defines the binary system interface between applications and the operating system on which they run. [Learn More](https://en.wikipedia.org/wiki/Application_binary_interface). +**A**pplication **B**inary **I**nterface. ABI is a document that comprehensively defines the binary system interface between applications and the operating system on which they run. [Learn More at Wikipedia](https://en.wikipedia.org/wiki/Application_binary_interface) or [pypackaging-native](https://pypackaging-native.github.io/background/binary_interface). diff --git a/docs/maintainer/infrastructure.md b/docs/maintainer/infrastructure.md index d2d6f31c05..ee4cacc6de 100644 --- a/docs/maintainer/infrastructure.md +++ b/docs/maintainer/infrastructure.md @@ -306,8 +306,28 @@ take more serious actions, including archiving feedstocks or removing maintainer conda-forge builds and maintains its own set of compilers for various languages and/or systems (e.g., `C`, `FORTRAN`, `C++`, `CUDA`, etc.). These are used -in all of our CI builds to build both core dependencies (e.g., `Python`) and maintainer-contributed -packages. While we do not have any formal policies or promises of support for these +in all of our CI builds to build essentially all artefacts published by conda-forge. + +This compiler infrastructure has a critical role beyond building everything, which +is to ensure that packages stay compatible with each other. This is due to how compiled +packages have a so-called [Application Binary Interface](../glossary.md#abi) +(ABI), and how changes in the compiler infrastructure may break this ABI, leading +to crashes, miscalculations, etc. Generally speaking, using a consistent compiler +version greatly reduces the risk of ABI breaks. + +In the past, changes in the compiler upgrades in conda-forge sometimes required a +full rebuild of basically all compiled packages, to avoid breakage between packages +that have been compiled to different ABIs. Compilers also have different policies in +this regard: GCC promises to never break ABI, while MSVC changed (=broke) ABI with +every compiler release (although this is not the case anymore for the `vc14` series +currently covering VS2015-VS2022). + +While it is likely that large-scale ABI breaks will happen again which require +a full rebuild of conda-forge (e.g. MSVC is planning a vNext after `vc14`), in recent +years we have managed to use more targetted rebuilds with less disruptive roll-outs. + +We keep our policies for full rebuilds in place for the next time it will occur. +While we do not have any promises of support for a generation of ABI-compatible compilers, we have historically maintained them according to the following (non-binding) principles. @@ -315,11 +335,11 @@ principles. and platforms is the [conda_build_config.yaml](https://github.com/conda-forge/conda-forge-pinning-feedstock/blob/master/recipe/conda_build_config.yaml) in the [conda-forge/conda-forge-pinning-feedstock](https://github.com/conda-forge/conda-forge-pinning-feedstock) as described in [Globally pinned packages](pinning_deps.md#globally-pinned-packages). -* We provide no support of any kind in terms of the long-term stability of these pinnings. +* We provide no support of any kind in terms of the long-term stability/support of a given compiler generation. * We upgrade them in an ad-hoc manner on a periodic basis as we have the time and energy to do so. Note that because of the way we enforce runtime constraints, these compiler upgrades will not break existing packages. However, if you are using the compilers outside of `conda`, then you may find issues. -* We generally provide notice in the form of an announcement when a compiler is going to be upgraded. +* We generally provide notice in the form of an announcement when an ABI-incompatible compiler change is going to happen. Note that these changes take a bit of time to complete, so you will generally have time to prepare should you need to. * Some of the criteria we think about when considering a compiler migration include: @@ -327,15 +347,95 @@ principles. - the amount of work for the `core` team, - the amount of time it will cost our (volunteer) feedstock maintainers. -We do use some unofficial names for our compiler stack internally. Note however that -the existence of these names does not imply any level of support or stability for the compilers +These compiler generations may or may not have some unofficial names for our +internal use (e.g. `comp7`). We note again that the existence of these names +does not imply any level of support or stability for the compilers that form the given stack. -* Our current compiler stack is referred to internally as `comp7`. -* The previous compiler stack based in part on the various `toolchain_*` packages - was sometimes referred to as `comp4`. On linux the `toolchain_*` compilers were - GCC 4.8.2 as packaged in the devtoolset-2 software collection. On osx, we use clang from - Apple's Xcode in the `toolchain_*` packages. +For the cases that do not require a complete rebuild of conda-forge (i.e. if the ABI +of a new compiler remains compatible), we can just increase the version in our global +pinning, and it will slowly roll out to the ecosystem as feedstocks get rerendered. + +For such ABI-compatible upgrades, similar but looser principles apply: + +* The pins are similarly defined in the global pinning, see [Globally Pinned Packages](pinning_deps.md#globally-pinned-packages). +* We provide no support of any kind in terms of the long-term availability of a given compiler version. +* We generally provide notice in the form of an announcement when a compiler is going to be upgraded. +* Without promising any timelines, our compilers on Linux and OSX are normally + very recent; on Windows, we generally use the last supported VS version. + +Despite the lack of explicit support, we try to keep the compilers in their various versions +working also outside of conda-forge, and even provide an easy way to install them +(through the [compilers feedstock](https://github.com/conda-forge/compilers-feedstock)). + +More specifically, each compiler uses an _activation_ package that makes the difference +between it being merely present in a build environment, and it being used by default. +These will be installed when using `{{ compiler('xyz') }}` in `meta.yaml`, where +`'xyz'` is one of `'c', 'cxx', 'fortran', 'cuda', 'rust', 'go-cgo', 'go-nocgo'`. + +Our default compiler stack is made up very differently on each platform; each platform +has its own default compiler, with its own set of feedstocks that provide them. Due to historical +reasons (the way compilers are integrated with their OS, and the amount of +software written in them, etc.), the most impactful languages are C & C++ (though +Fortran is considered part of the default, not least because GCC compiles all three). + +Linux (GCC): + +* [C, C++, Fortran] Activation: https://github.com/conda-forge/ctng-compiler-activation-feedstock/ +* [C, C++, Fortran] Implementation: https://github.com/conda-forge/ctng-compilers-feedstock +* Note that when used in conjunction with CUDA, compiler versions are restricted by the + maximum GCC version supported by nvcc (which is also reflected in the global pinning). + +OSX (Clang): + +* [C, C++] Activation: https://github.com/conda-forge/clang-compiler-activation-feedstock/ +* [C, C++] Required feedstocks: + [llvmdev](https://github.com/conda-forge/llvmdev-feedstock), + [clangdev](https://github.com/conda-forge/clangdev-feedstock), + [compiler-rt](https://github.com/conda-forge/compiler-rt-feedstock), + [libcxx](https://github.com/conda-forge/libcxx-feedstock), + [openmp](https://github.com/conda-forge/openmp-feedstock), + [lld](https://github.com/conda-forge/lld-feedstock), + [cctools](https://github.com/conda-forge/cctools-and-ld64-feedstock) +* [Fortran] Activation: https://github.com/conda-forge/gfortran_osx-64-feedstock/ +* [Fortran] Implementation: https://github.com/conda-forge/gfortran_impl_osx-64-feedstock/ + +Windows (MSVC): + +* [C, C++] Activation: https://github.com/conda-forge/vc-feedstock + (we cannot redistribute the actual MSVC compilers due to licensing constraints) +* [Fortran] Activation & Implementation: https://github.com/conda-forge/flang-feedstock + +There exists an alternative, MinGW-based, compiler stack on Windows, which is available +with a `m2w64_` prefix (e.g. `{{ compiler('m2w64_c') }}`). However, it is falling out +of use now that most projects will natively support compilation also with MSVC, in addition +to several complications arising from mixing compiler stacks. + +Additionally, there is a possibility to use `clang` as a compiler on Linux & Windows: + +* Activation (Linux): https://github.com/conda-forge/clang-compiler-activation-feedstock/ +* Activation (Windows): https://github.com/conda-forge/clang-win-activation-feedstock/ + +Aside from the main C/C++/Fortran compilers, these are the feedstocks for the other compilers: + +* [CUDA] https://github.com/conda-forge/nvcc-feedstock (CUDA infra currently being overhauled) +* [Rust] [Activation](https://github.com/conda-forge/rust-activation-feedstock) + and [Implementation](https://github.com/conda-forge/rust-feedstock) +* [Go] [Activation](https://github.com/conda-forge/go-activation-feedstock) + and [Implementation](https://github.com/conda-forge/go-feedstock) + +To upgrade the compiler version of our default compilers in the global pinning for +Linux or OSX, ensure that the respective above-mentioned feedstocks have been rebuilt +for the new major version, that all interrelated versions are lifted at the same time, +and obviously that the compilers work (e.g. by testing them on some feedstocks by +specifying the new version through the feedstock-local `conda_build_config.yaml`). +You should also check the compiler release notes for warnings about ABI incompatibilities, +and mention any such notices in the discussion about the upgrade. + +For Windows, we stay on older compilers for longer, because using a newer toolchain +would force everyone wanting to locally develop with conda-forge artefacts to use +a toolchain that's at least as new. You can find more details about this topic in this +[issue about updating to the vc142 toolchain](https://github.com/conda-forge/conda-forge.github.io/issues/1732). From 4feb1e9bbfccec339096930c006e36f01f0be650 Mon Sep 17 00:00:00 2001 From: "H. Vetinari" Date: Thu, 21 Mar 2024 05:19:59 +1100 Subject: [PATCH 2/5] fix link for clang-on-linux compiler activation --- docs/maintainer/infrastructure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/maintainer/infrastructure.md b/docs/maintainer/infrastructure.md index 20688ff9b3..a5503c992b 100644 --- a/docs/maintainer/infrastructure.md +++ b/docs/maintainer/infrastructure.md @@ -414,7 +414,7 @@ to several complications arising from mixing compiler stacks. Additionally, there is a possibility to use `clang` as a compiler on Linux & Windows: -- Activation (Linux): https://github.com/conda-forge/clang-compiler-activation-feedstock/ +- Activation (Linux): https://github.com/conda-forge/ctng-compiler-activation-feedstock/ - Activation (Windows): https://github.com/conda-forge/clang-win-activation-feedstock/ Aside from the main C/C++/Fortran compilers, these are the feedstocks for the other compilers: From bae6442cd0109f362fc6cbc3d1e1064951869137 Mon Sep 17 00:00:00 2001 From: "H. Vetinari" Date: Fri, 22 Mar 2024 10:41:04 +1100 Subject: [PATCH 3/5] update CUDA compiler info --- docs/maintainer/infrastructure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/maintainer/infrastructure.md b/docs/maintainer/infrastructure.md index a5503c992b..f17aa84735 100644 --- a/docs/maintainer/infrastructure.md +++ b/docs/maintainer/infrastructure.md @@ -419,7 +419,7 @@ Additionally, there is a possibility to use `clang` as a compiler on Linux & Win Aside from the main C/C++/Fortran compilers, these are the feedstocks for the other compilers: -- [CUDA] https://github.com/conda-forge/nvcc-feedstock (CUDA infra currently being overhauled) +- [CUDA] [CUDA 12.0+](https://github.com/conda-forge/cuda-nvcc-feedstock) & [CUDA <12](https://github.com/conda-forge/nvcc-feedstock) (legacy) - [Rust] [Activation](https://github.com/conda-forge/rust-activation-feedstock) and [Implementation](https://github.com/conda-forge/rust-feedstock) - [Go] [Activation](https://github.com/conda-forge/go-activation-feedstock) From 8a792a809f7e35b1723128e78189fcc173316fd9 Mon Sep 17 00:00:00 2001 From: "H. Vetinari" Date: Fri, 22 Mar 2024 11:05:28 +1100 Subject: [PATCH 4/5] rewrite section about compiler ABI-compatibility --- docs/maintainer/infrastructure.md | 38 +++++++++++++++++++------------ 1 file changed, 23 insertions(+), 15 deletions(-) diff --git a/docs/maintainer/infrastructure.md b/docs/maintainer/infrastructure.md index f17aa84735..5f21e2ebaf 100644 --- a/docs/maintainer/infrastructure.md +++ b/docs/maintainer/infrastructure.md @@ -316,19 +316,26 @@ packages have a so-called [Application Binary Interface](../glossary.md#abi) to crashes, miscalculations, etc. Generally speaking, using a consistent compiler version greatly reduces the risk of ABI breaks. -In the past, changes in the compiler upgrades in conda-forge sometimes required a -full rebuild of basically all compiled packages, to avoid breakage between packages -that have been compiled to different ABIs. Compilers also have different policies in -this regard: GCC promises to never break ABI, while MSVC changed (=broke) ABI with -every compiler release (although this is not the case anymore for the `vc14` series -currently covering VS2015-VS2022). - -While it is likely that large-scale ABI breaks will happen again which require -a full rebuild of conda-forge (e.g. MSVC is planning a vNext after `vc14`), in recent -years we have managed to use more targetted rebuilds with less disruptive roll-outs. - -We keep our policies for full rebuilds in place for the next time it will occur. -While we do not have any promises of support for a generation of ABI-compatible +Compilers generally strive to maintain ABI-compatibility across versions, meaning that +combining artefacts for the same target produced by different versions of the same +compiler will work together without issue. Due to the nature of the ABI (i.e. a vast +interface between software and hardware, with innumerable corner cases), it still +happens that unintentional changes for some specific aspect are introduced across +compiler versions, though in practice this does not lead to wide-spread issues. + +In contrast, when compilers do intentionally change the ABI (as MSVC did with each +release before the `vc14` series currently covering VS2015-VS2022), _every_ compiled +package needs to be rebuilt for that new ABI, and cannot be mixed with builds for the +old ABI. While less likely nowadays, in principle it's also possible that a major +infrastructural overhaul in the compiler stack similarly forces a complete rebuild. + +Such large-scale changes -- requiring +/- all of conda-forge to be rebuilt -- take a +lot of effort, though thankfully, in recent years such full rebuilds have not been +necessary and we managed to do less disruptive compiler upgrades. + +However, large-scale ABI breaks remain a possibility (e.g. MSVC is planning a vNext +after `vc14`), and so we keep our policies for such a scenario in place. +While we do not have any formal promises of support for a generation of ABI-compatible compilers, we have historically maintained them according to the following (non-binding) principles. @@ -354,8 +361,9 @@ does not imply any level of support or stability for the compilers that form the given stack. For the cases that do not require a complete rebuild of conda-forge (i.e. if the ABI -of a new compiler remains compatible), we can just increase the version in our global -pinning, and it will slowly roll out to the ecosystem as feedstocks get rerendered. +of a new compiler remains compatible, up to rare corner cases), we can just increase +the version in our global pinning, and it will slowly roll out to the ecosystem as +feedstocks get rerendered. For such ABI-compatible upgrades, similar but looser principles apply: From cb62654c95900db660406c9a0eedaaf2bb30bf55 Mon Sep 17 00:00:00 2001 From: "H. Vetinari" Date: Fri, 22 Mar 2024 11:19:17 +1100 Subject: [PATCH 5/5] em-dash --- docs/maintainer/infrastructure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/maintainer/infrastructure.md b/docs/maintainer/infrastructure.md index 5f21e2ebaf..1255df0b6d 100644 --- a/docs/maintainer/infrastructure.md +++ b/docs/maintainer/infrastructure.md @@ -329,7 +329,7 @@ package needs to be rebuilt for that new ABI, and cannot be mixed with builds fo old ABI. While less likely nowadays, in principle it's also possible that a major infrastructural overhaul in the compiler stack similarly forces a complete rebuild. -Such large-scale changes -- requiring +/- all of conda-forge to be rebuilt -- take a +Such large-scale changes – requiring +/- all of conda-forge to be rebuilt – take a lot of effort, though thankfully, in recent years such full rebuilds have not been necessary and we managed to do less disruptive compiler upgrades.