Optional (dev) build.rs

[stanislav-tkach]

build.rs can be used for optional checks such as skeptic. In that case it isn't convenient (especially for the library) to run it each time. So it will be useful to have "dev" build.rs similar to dev-dependencies.

[lukaslueg]

Aren't the environment variables enough for that? Cargo sets environment variables PROFILE to debug before calling the build script in all non-release builds. The build script can check for that and skip skeptic et al.

[stanislav-tkach]

As for me, an environment variable isn't enough: library users don't need such check even for the debug build. It is OK as a workaround (I still prefer to handle it somehow through CI script), but it would be nice to have "native" support.

One more thing: build script is a really powerful thing that can be used for different purposes. As a third-party crate user I need to analyze why it is needed. If there is a separate dev-build.rs (and no regular build.rs) then I will have one less thing to worry about.

[richard-uk1]

I've made a package called cpu-monitor, that has minimal dependencies apart from skeptic. Unfortunately skeptic pulls in a lot of stuff that isn't necessary apart from for testing, which makes people not want to use my crate.

This would still hit them in debug mode.

I'm going to experiment with solutions, probably a feature flag that is required to run skeptic, but as @DarkEld3r says, it would be nice to have a canonical solution to this problem.

[epage]

A use case for this was also brought up in #3404 with generating tests.

Personally, I would prefer something like #3404 which is a lot more general.

[Xanewok]

It seems I have a use case for this (or #12552?).

At https://github.com/NomicFoundation/slang, we're using Cargo to generate a final package to be published using a custom build pipeline - the generated code is checked-in (easier to review/audit) and verified that it's up to date by the CI (as a side-note, we're also generating tests but that's orthogonal).

However, to ensure that the package is re-built correctly by Cargo when working locally, we need to include a build script (that we don't actually want to publish).

We're currently working around that by including a build script that checks a marker env var and does local codegen if it's needed but that's somewhat of a workaround and we also need to run a custom cargo build, which leads to deadlock issues (i.e. #6412, we're working around that with a custom target-dir).

Another workaround is to use a build-dependency on a workspace-local crate that does the codegen, but we'd have to patch the manifest and strip it out before we publish the package.

See NomicFoundation/slang#597 (comment) for a more in-depth write-up about our use case.