Closed h-vetinari closed 4 months ago
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.
I'll defer to @isuruf. This feedstock has moved beyond me.
Obsoleted by #102
This is a continuation of #100, with the main change of not building clang alongside, but elevating it to a separate build, in the spirit of Isuru's statement:
Clang is a full-fledged compiler for linux, so I'd like to treat it like one (by being able to build for several versions). The only overlap between
compiler_vendor == "gcc"
and"clang"
is thatbinutils_{{ cross_target_platform }}
gets built in each job, but will only be uploaded once (due to coinciding hashes). This is already the case before this PR for different GCC versions, so that should be a non-issue IMO.Rather than building
clang 16 x gcc {11, 12, 13}
(like in #100), I'd prefer to buildclang {16, 17, y} x gcc {base}
. The interaction with the GCC version only comes in through the dependence onlibgcc-devel_{{ cross_target_platform }}
, and I think it's more worthwhile to cover more clang versions, than to enable only old(er) clang, but with all versions of libgcc-devel.I actually also wanted to tackle https://github.com/conda-forge/clang-compiler-activation-feedstock/issues/118, but realized that we cannot introduce
clang
/clangxx
outputs without renaming them on the clangdev feedstock first.