DEP_FOO_KEY-like system that can work without "links"

[dwrensha]

Would it make sense to allow usage of DEP_<name>_<key environment variables in a build.rs for dependencies that do not link to native libraries?

Context: I would like to allow crates like this one to expose Cap'n Proto schema definitions, and in particular to allow Cap'n Proto's import mechanism to work across crate boundaries. (See capnproto/capnpc-rust#30.)

For example, say I write a my_app crate that depends on the sandstorm crate, and I want my_app to have some capnp schemas that import from the sandstorm schemas. For this to work, the my_app build.rs needs to know where to find the source code of the sandstorm schemas. One way to accomplish that would be for the sandstorm crate's build.rs to write its current working directory to a DEP_SANDSTORM_IMPORT environment variable, through the mechanism described here. However, that only works if the sandstorm crate has a "links" field in its Cargo.toml. Since the sandstorm crate does not actually need to link to a native library, adding such a field feels superfluous and possibly prone to mysterious bugs.

[alexcrichton]

Yeah I've often desired such a feature as well. I've had difficulty rationalizing in the past what <name> would be, however, to disambiguate from other crates. For example if two versions of the same library are linked into a crate how would those keys be passed to the build script? Cargo doesn't support this feature today, but it may wish to one day.

Other than that though it seems like a reasonable feature to me!

[sfackler]

You can't depend directly on two versions of the same crate though, right? Are DEP_* variables from transitive dependencies exposed to build scripts?

[alexcrichton]

@sfackler not currently, no, but I could imagine adding that as a feature to Cargo at some point. I think we'd only want to expose immediate dependencies to build scripts, not transitive, as that'd make the problem much easier (and more practical I think)

[alexcrichton]

Well so we may be able to actually just go ahead and do this.

So Cargo will pass a number of --extern flags with some name. That is the namespace for incoming crates. If Cargo ever supports multiple versions it'll have to support renaming crates anyway (e.g. renamed when passing to --extern. In that sense I think it's safe to say there's a namespace here anyway and it will fit naturally into the env vars.

We'd probably want to spec that the name in the env var though is the name of the library, not the name of the package. That differs in a few rare cases but would future-proof us a bit.

[retep998]

You currently can depend on two crates that have the same library name, yet different package names, even straight from crates.io.

[SimonSapin]

I fully expected <name> to be the crate/package’s name, was confused for quite some time as to why by dependen’t build script did not get any DEP_* environment variable, and only finally figured it out by reading Cargo’s own test suite.

I’ve ended up adding to a crate a links key with a dummy value.

[retep998]

As far as I can tell these DEP_* keys are the only way we have to provide information to downstream consumers (which is really important when the functionality that the crate exposes is controlled by the user rather than the highly restrictive cargo features). The fact that links has to be specified to be able to use this feature is a real hassle, especially for crates that don't want cargo to limit them to only a single version (otherwise this happens).

[alexcrichton]

I'll again refer to my previous comments:

• Not originally done due to suspected name collisions.
• Original thoughts seem incorrect, should be possible to implement!

@SimonSapin @retep998 if you'd like to send a PR for this it'd definitely be most welcome!

[retep998]

If we do add DEP_* keys following the crate name, what do we do when there are collisions with the existing DEP_* keys using the links value? Would we effectively declare the old way deprecated and only provide DEP_* keys using links when they don't conflict with a crate name?

[alexcrichton]

We could just use a different namespace, such as CARGO_DEP_FOO_KEY=value

[sfackler]

I think it'd be a good idea in general to start migrating to a CARGO_ prefix on environment variables.