rust/library/compiler-builtins/builtins-test-intrinsics/build.rs

mod builtins_configure {
    include!("../compiler-builtins/configure.rs");
}

fn main() {
    println!("cargo::rerun-if-changed=../configure.rs");

    let target = builtins_configure::Target::from_env();
    builtins_configure::configure_aliases(&target);
}
Move `examples/intrinsics.rs` to its own crate Currently there is an interesting situation with the way features get enabled; `testcrate` enables `mangled-names`, but the `intrinsics.rs` example requires this feature be disabled (otherwise the test fails with missing symbols, as expected). This is also the reason that `testcrate` is not a default workspace member, meaning `cargo test` doesn't actually run `testcrate`'s tests; making it a default member would mean that `compiler-builtins/mangled-names` gets enabled when `examples/intrinsics.rs` gets built, due to the way features get unified. Simplify the situation by making moving the example to its own crate as `builtins-test-intrinsics`. This also means `testcrate` can become a default member so it is included in `cargo check` or `cargo test` when run at the workspace root. `testcrate` and `builtins-test-intrinsics` still can't be built at the same time since there isn't a straightforward way to have Cargo build `compiler-builtins` twice with different features. This is a side effect of us using non-additive features, but there isn't really a better option since enabling both mangled and unmangled names would render `builtins-test-intrinsics` useless. 2025-03-18 10:13:47 +00:00			`mod builtins_configure {`
Switch repository layout to use a virtual manifest The current setup has the `Cargo.toml` for `compiler-builtins` at the repository root, which means all support crates and other files are located within the package root. This works for now but is not the cleanest setup since files that should or shouldn't be included in the package need to be configured in `Cargo.toml`. If we eventually merge `libm` development into this repository, it would be nice to make this separation more straightforward. Begin cleaning things up by moving the crate source to a new `compiler-builtins` directory and adding a virtual manifest. For now the `libm` submodule is also moved, but in the future it can likely move back to the top level (ideally `compiler-builtins/src` would contain a symlink to `libm/src/math`, but unfortunately it seems like Cargo does not like something about the submodule + symlink combination). 2025-03-19 05:19:17 +00:00			`include!("../compiler-builtins/configure.rs");`
Move `examples/intrinsics.rs` to its own crate Currently there is an interesting situation with the way features get enabled; `testcrate` enables `mangled-names`, but the `intrinsics.rs` example requires this feature be disabled (otherwise the test fails with missing symbols, as expected). This is also the reason that `testcrate` is not a default workspace member, meaning `cargo test` doesn't actually run `testcrate`'s tests; making it a default member would mean that `compiler-builtins/mangled-names` gets enabled when `examples/intrinsics.rs` gets built, due to the way features get unified. Simplify the situation by making moving the example to its own crate as `builtins-test-intrinsics`. This also means `testcrate` can become a default member so it is included in `cargo check` or `cargo test` when run at the workspace root. `testcrate` and `builtins-test-intrinsics` still can't be built at the same time since there isn't a straightforward way to have Cargo build `compiler-builtins` twice with different features. This is a side effect of us using non-additive features, but there isn't really a better option since enabling both mangled and unmangled names would render `builtins-test-intrinsics` useless. 2025-03-18 10:13:47 +00:00			`}`

			`fn main() {`
			`println!("cargo::rerun-if-changed=../configure.rs");`

			`let target = builtins_configure::Target::from_env();`
			`builtins_configure::configure_aliases(&target);`
			`}`