[llvm-branch-commits] [clang] [flang] [lld] [llvm] [Flang] LLVM_ENABLE_RUNTIMES=flang-rt (PR #110217)
via llvm-branch-commits
llvm-branch-commits at lists.llvm.org
Mon Dec 16 17:05:54 PST 2024
h-vetinari wrote:
> @h-vetinari Is this using a bootstrap or default-only build? Is flang built in-tree or out-of-tree? Is `flang` in the build- or install-tree? Did you check whether the `flang_rt.static.lib` is present?
>
> I am going to test more configurations under Windows trying to reproduce this. Narrowing it down would help.
On a basis of already-compiled & installed `llvm` (the subproject), clang, mlir, compiler-rt, we first build flang, and then flang-rt using the just-built flang. Both get installed (ultimately) into the same install tree where the other LLVM bits are already present*, so in the end it should be pretty standard -- all in one place. I did check that `flang_rt.static.lib` is present (under the path I described, i.e. `/lib/windows/flang_rt.static.lib`, relative to `CMAKE_INSTALL_PREFIX`).
<details>
<summary>* details</summary>
this is actually the mechanism that defines what the "installation" of a given package X means from the POV of conda-build; i.e. populate the the install-tree with whatever needs to be there, take a snapshot before and after installation, then the (positive) delta between the before/after snapshots defines the content of X _as installed_.
For testing, there's a further level of isolation from the build environment, in that everything gets torn down and then recreated based on what has been determined to be the package content (plus all specified dependencies), and _then_ run the tests. This is to avoid spuriously relying on stuff from the build tree, and forcing the installation to be explicit about what it needs to put into the installation-`$PREFIX`. It also ends up testing/enforcing relocatability (which needs some more magic on linux, but it's possible).
</details>
In sequence, we do:
* set up install-tree with the (LLVM) bits required to build flang
* build [flang](https://github.com/h-vetinari/flang-feedstock/blob/dev/recipe/bld.bat)
* build [flang-rt](https://github.com/h-vetinari/flang-feedstock/blob/dev/recipe/install_flang-rt.bat)
* [build some wrappers that just add metadata]
* run tests
Everything is held together by a [recipe](https://github.com/h-vetinari/flang-feedstock/blob/dev/recipe/meta.yaml), but I don't expect that to be immediately self-evident (happy to explain what's happening though!).
So for the final test, we create an environment that looks like
```
TEST START: C:\bld\win-64\flang_win-64-20.0.0.dev3-h0d486fc_0.conda
[...]
## Package Plan ##
environment location: C:\bld\flang-split_1734298984217\_test_env
The following NEW packages will be INSTALLED:
clang: 20.0.0.dev3-default_h00e4eaa_0 conda-forge/label/llvm_dev
clang-20: 20.0.0.dev3-default_h00e4eaa_0 conda-forge/label/llvm_dev
compiler-rt: 20.0.0.dev3-h85af4db_0 conda-forge/label/llvm_dev
compiler-rt_win-64: 20.0.0.dev3-h85af4db_0 conda-forge/label/llvm_dev
flang: 20.0.0.dev3-hb33b443_0 local
flang-rt: 20.0.0.dev3-h963887e_0 local
flang_impl_win-64: 20.0.0.dev3-h0d486fc_0 local
flang_win-64: 20.0.0.dev3-h0d486fc_0 local
libiconv: 1.17-hcfcfb64_2 conda-forge
libllvm20: 20.0.0.dev3-h7de1732_0 conda-forge/label/llvm_dev
libxml2: 2.13.5-he286e8c_1 conda-forge
libzlib: 1.3.1-h2466b09_2 conda-forge
lld: 20.0.0.dev3-h4ef2093_0 conda-forge/label/llvm_dev
llvm-tools: 20.0.0.dev3-h6f9bbfe_0 conda-forge/label/llvm_dev
ucrt: 10.0.22621.0-h57928b3_1 conda-forge
vc: 14.3-ha32ba9b_23 conda-forge
vc14_runtime: 14.42.34433-he29a5d6_23 conda-forge
zstd: 1.5.6-h0ea2cb4_0 conda-forge
```
The `local` packages are the ones that have just been built (not yet published); the ones from the `llvm_dev` label have been built & published previously (but from the same commit). `flang{,_impl}_win-64` are the metapackages I mentioned that don't change anything.
The testing order follows the DAG of dependencies, IOW, since `flang_win-64` (the final compiler) depends on `flang-rt`, the tests for `flang-rt` have already run before, and I've explicitly [tested](https://github.com/h-vetinari/flang-feedstock/blob/e86a0e2a0ab30056f6d924dcd4668ec975328767/recipe/meta.yaml#L60) the presence of `flang_rt.static.lib` _as installed_. In particular, this guarantees that this library is in the expected location when we end up testing `flang_win-64`.
Here are the full [logs](https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=1110855&view=results) if you're interested (note that azure pipelines deletes the logs after a month).
https://github.com/llvm/llvm-project/pull/110217
More information about the llvm-branch-commits
mailing list