[rc] Add llvm-tools-<maj> on windows as well

[h-vetinari]

No description provided.

[conda-forge-webservices]

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/meta.yaml) and found it was in an excellent condition.

[conda-forge-webservices]

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/meta.yaml) and found it was in an excellent condition.

I do have some suggestions for making it better though...

For recipe/meta.yaml:

• No valid build backend found for Python recipe for package lit using pip. Python recipes using pip need to explicitly specify a build backend in the host section. If your recipe has built with only pip in the host section in the past, you likely should add setuptools to the host section of your recipe.

[conda-forge-webservices]

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/meta.yaml) and found it was in an excellent condition.

[h-vetinari]

Or couldn't we compile our own wrapper-exe (per binary) that just calls the versioned one from C

I just tried that now. It's not as light as a symlink, but waaaay lighter than copying. Each binary takes ~12kb; for 80 binaries in llvm-tools, that amounts to less than 1 MB, which I think is negligible (certainly compared to 300MB if we copied).

590f8d1 is obviously not meant for merge/review (logs with that commit), but it shows that the forwarder is robust enough to replace %LIBRARY_BIN%\cmake during the build and have all the rest work out.

Would appreciate your thoughts @isuruf

[isuruf]

What's the license on this?

[h-vetinari]

MIT, see here, which covers the code in doc source

[h-vetinari]

Any other concerns besides the license?

[h-vetinari]

Gentle ping on this @isuruf

[h-vetinari]

Another ping here... I'm aware this is a trade-off between consistency across platforms and extra complexity (though we hopefully shouldn't have to touch it going forward; might also consider breaking this out into something reusable wherever we have versioned binaries). I don't have a clear answer what is better, so I'd appreciate your input @isuruf.

[isuruf]

Can we just use symlink-exe-substitute-feedstock ?

[h-vetinari]

It looks like that's built to symlink an exe into another folder, not to a differently-named file in the same folder (it also doesn't use the relative path logic). That said, the approach could probably be extended to name the target symlink, and it's cleaner because it doesn't duplicate the 12kb per link (at the cost of introducing an extra run-dependency).