Pass parameters to build.rs script via CLI

[kolipka]

Hello,
I use make to call cargo build for few modules. For one of them I have to generate some code based on folder structure. I need to pass that folder location via CLI, since it can change. For now I pass it via env var, but it is not nice in multiplatform make. It looks more like workaround than real solution.

I think it could be something like:
cargo build --release -- folder=/my/folder

build.rs could receive everything after -- via std::env::args()

Thanks!

[alexcrichton]

Currently this is typically done through environment variables, would that work for you?

[kolipka]

Yes and no: I plan to do it that way, but this adds more complexity to makefile: I have to set environment variables differently for Linux and Windows where it is ugly (cmd /V /C "set VAR123=$(CC) && echo !VAR123!"). It gets more ugly when having more variables. Because of that I consider to stop using build.rs and do stuff in Python.
Having such variables in build.rs I could remove my .sh/.cmd/.py scripts from build system and write it in nice multiplatform way in one language -> huge benefit.

BTW:
I have to cargo clean first since I have to force rebuild - cargo will not rerun build.rs when environment variable will change. I would like to decide from build.rs that I want to rebuild(I was planning to use cargo:rerun-if-changed=... but now does not make sense since I have to rebuild anyway).

[alexcrichton]

If you're writing a Makefile, instead of doing this:

foo:
    cargo build --some-argument foo

can't you do this?

foo: export FOO=foo
foo:
    cargo build

[kolipka]

For linux I can do
FOO=foo cargo build
but for Windows no.
I can call cargo_build.sh or cmd that will set this env variable, but it is still just a workaround, and does not solve problem in Cargo.

I know I am picky, and I don't waste your time: is it OK if I make PR with handling those params in this way(it is like in npm run Or passing params to build script is against some idea about cargo?

[alexcrichton]

Does the environment variable syntax in the makefile work? That tends to be more portable than bash itself.

[kolipka]

I made PR to have CLI parameters feature.

Env var syntax in make works. My opinion about using it is bad. I think that it is just like global scope - polluting it makes only problems. In small build systems I can control it. In bigger, you never know who, when and why changed variable you use. Especially when there is large number of dependencies.

[omarabid]

I agree with @kolipka. I think it's cleaner (and simpler) to support arguments for build.rs. It seems that this feature has staled.

[epage]

I feel like whats missing from this issue is use cases for why flags are being passed to build.rs.

[epage]

I've created a Pre-RFC for mutually-exclusive, global features which might be pertinent to the discussion.

[ZhekaS]

I feel like whats missing from this issue is use cases for why flags are being passed to build.rs.

For one, I am using bindgen that is generating bindings for a specific C library, and it needs to take a bunch of paths in the filesystem, such as the path to the headers and to the sysroot, which is depending on a specific toolchain being used. Hardcoding these in the build.rs is a bad idea. Passing these via env variables and wrapping cargo invocation in Makefile is a bad idea too, as it is used i a lib crate which is compiled as a dependency from another crate.
An ideal solution would be to have a way to communicate the settings from Cargo.toml to build.rs in more versatile fashion than the current feature mechanism. For example provide a way of setting env variables from the Cargo.toml

[epage]

In #14903 (comment), I propose Cargo.toml configuring build scripts. However, that is for a different use case. If you can edit Cargo.toml to put this in, then why not build.rs?

[ZhekaS]

In #14903 (comment), I propose Cargo.toml configuring build scripts. However, that is for a different use case. If you can edit Cargo.toml to put this in, then why not build.rs?

Well, I afraid it is going to slide off-topic, but the main idea is that a crate and it's dependencies could be configured in the top-level manifest, similarly
to how current features work. If we go with env setting, it would be pretty much straight forward, but not very hygienic. But if we introduce arbitrary flag settings in addition to feature/cfg, which can be also passed per dependency, it might solve many limitations (analogous to the -Dsymbol in gcc, which is extremely useful).

[epage]

Ah, you are looking for transitive dependencies. global features could help with that.