build bolt #276
build bolt #276
Conversation
|
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 ( |
h-vetinari
requested review from
JohanMabille,
SylvainCorlay,
inducer,
isuruf,
jakirkham,
mingwandroid,
timsnyder and
xhochy
as code owners
|
@conda-forge/llvmdev @conda-forge/core I tried adding bolt a couple of times in conda-forge/staged-recipes#22204, but standalone builds are unsupported, and the recommended way is to build this as part of building The main downside of doing this in this feedstock is that this would further blow up the build time here, and we're already prone to hitting timeouts on the slower agents. Alternatively, we could create a separate feedstock that rebuilds The latter would be my preferred approach for various reasons, and I can easily transfer the changes from here to conda-forge/staged-recipes#22204. For now I'm still using this feedstock because it nicely shows the incremental changes, without getting lost in the noise if copied to staged-recipes. Would appreciate your thoughts! |
That sounds like something that can easily get out of sync. If we really need to do this because of build times, I would be Ok with it, but would very much prefer to avoid it. |
Both feedstocks would get built from the same version/commit. Or do you mean differences arising from mismatched build options? |
|
I'm mostly worried about diverging build scripts. |
|
@isuruf, any thoughts on this? |
|
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 ( |
|
I'm mostly concerned about the build timeouts on windows; the last run took 3 attempts to complete, if that happens similarly after merging, we're looking at ~36h minimum to unblock the central feedstock upon which the rest LLVM stack builds for any new version (and that's assuming timely restarts and no other build failures to take care of). If we decide to build bolt on this feedstock, then at least I'd want to be able to skip the bolt builds for a new version. |
|
Then it's better to build as a separate feedstock. It should be possible to reduce the build time by building only the x86_64 and aarch64 backends as bolt only supports those. |
|
We could also drop the That would save us up to ~2h runtime on a slow windows agent (using the logs from the latest run that failed here), which would put us firmly back into the green again. We've already skipped the tests on osx for llvm 18 due to timeouts (cebf7e9). Middleground would be to still keep running the lit tests on osx/win, but don't bother with |
This reverts commit cebf7e9.
|
OK, nevermind, I was so convinced that the job that timed out job was windows that I didn't see that I was looking at linux logs for ce3e17c 🙈 |
|
On windows now, the lit tests took: In other words, roughly half an hour we could save |
don't run check-llvm on osx but keep lit checks on windows, we drop the lit tests too
…nda-forge-pinning 2024.07.23.22.35.38
It seems supports risc-v as well... The problem is that the variable for target support is sounds llvm-wide and not bolt-specific (see README): AFAIU we shouldn't touch that on linux (assuming we're still on llvmdev), or we'd have trouble cross-compiling to ppc? But we could switch it off on osx/win. |
I meant, we can do it in a separate feedstock with reduced architectures. We shouldn't reduce architectures here. |
|
Or we wait for llvm/llvm-project#97130. Either way, let's not package bolt in this feedstock. |
Thanks for the reference. OK, I'll update conda-forge/staged-recipes#22204 |
Building bolt as standalone is not supported upstream (c.f. conda-forge/staged-recipes#22204), the README recommends building it as part of llvmdev. Let's try that here...
Xref #147