Add built-at-build crate

[baxterjo]

I wanted the ability to access the built information at build time. I originally opened an issue but decided that I didn't like the struct approach and instead a dependent crate would make more sense. This way you can even get compile time checking in the build script.

I'm not married to the name of the crate or the specific implementation, I just want the feature.

Thanks!

[lukaslueg]

Thanks for the PR. I'm not entirely sure if I understand the intention of this code: Is this code supposed to be published to crates.io, for people to depend on it instead of built?

[baxterjo]

Thanks for the PR. I'm not entirely sure if I understand the intention of this code: Is this code supposed to be published to crates.io, for people to depend on it instead of built?

Thanks for the quick response.

The use case is when you want to access the info provided by built in build.rs instead of writing the info in build.rs. Users that want to continue using built info in their applications would still depend on built as a build dependency. But if you want to access that info in your build script you would add this crate under [build-dependencies] in your Cargo.toml.

The specific use case I am submitting this PR for is comparing pre-compiled static library build environments to the binary that I am actively compiling in build.rs that necessitates accessing these vars at build time.

Use Case Example

1. Given an example static lib: libffiexample.a that I own and is built in CI with a specific environment / toolchain.
2. I do some c header magic in the source code of libffiexample.a to bake the environment strings provided by built into the resulting object artifact file. (At this point I am still using the released built crate)
3. In build.rs for my binary that uses libffiexample.a I unpack and interpret those environment strings from libffiexample.a so I know the exact environment this static lib was built with.
4. In the same build.rs I need access to my current build environment for comparison. (This is where the PR is needed)

The root cause for needing this comparison is that when doing Rust <-> Rust ffi, some platforms will throw cryptic linker errors when build toolchains don't match between static libs and binaries using them.

Alternate Path

An alternate option would be to include this functionality in the build.rs of the built crate. Although I'm not sure users would like an implicit action like this without some input.

[lukaslueg]

AFAICS the use-case here falls into the category of mad-scientist things people need to do in niche cases. Mad scientists do important science stuff as well, yet we never run out of use-cases, while having no hope for a truly transparent build system.

I'd be hesitant to add an "official" crate for the sole purpose of observing that crate while building another, as 1) there will always be another use-case that is slightly different and needs another knob, 2) downstream can always add their own crate (or code-duplication) to do exactly that, and 3) there is a considerable case to be made that built overburdens transient-upstream already, especially when crates are packaged for distribution (e.g. Debian).

In that light, I'd rather

• add this as a recipe/code-example, or
• expose built's internals to the build-script itself. This has had been deliberately avoided, as people will invariably depend on behavior, even if we hang a sign on the front door "This is not a build-system replacement!"
• do nothing, and let the use-case simmer for a while longer

[baxterjo]

Ok, no worries. I had originally implemented this solution in my own crate and was about to hit release and realized it might be useful in this crate.

I think a recipe is a great idea. I'll get this PR edited into that. Would you prefer it go in example_project or should I make a new examples dir?

[lukaslueg]

Moving /example_project to /examples/example_project and creating /examples/witness should be fine. There are some paths in the .github workflows and example_project's manifest that need updating then.