Need a solution for loading out-of-tree module source

[brson]

Servo has two instances now where crates need to refer to generated modules that are created as part of another build step. Servo also only supports out-of-tree builds. The Rust parser expects to find source files laid out as a tree. As a result we are generating this source directly in the source tree and ignoring them with .gitignore. This is unpleasant.

I don't have any great ideas about how to make this work.

[brson]

Nominating for feature complete.

[metajack]

My only idea for this so far was basically adding an option to rustc to specify src search dirs, similarly to how -I foo works for cc. So if I said -I /path/to/foo and the compiler wanted bar/baz.rs, it would search /path/to/foo/bar/baz.rs as well.

[brson]

We could do something like the existing #[path = "foo.rs"] attribute that would change where the source is searched from.

#[path_root = cfg_str!(build_dir)] mod foo;

This would basically transplant the current relative module path onto a different directory when searching for foo, then the build would pass --cfg "build_dir = \"my_build_dir\"" to rustc. Pretty hideous. Requires macros that expand to literals (which would be useful for other things too).

[brson]

Or maybe just

#[path_dir = cfg_str!(generated_src_dir)] mod foo;

So we don't have to 'transplant' the relative directory onto the build dir root.

[emberian]

cc @jbclements @paulstansifer how do you feel about the macro-based solution above?

Personally I'd rather just change the attribute sublanguage to allow #[path_root=build_dir] and it would know to look in the list of cfg variables for that.

[jbclements]

generally speaking, I like the idea of using macros rather than extending the language... though it sounds like either one would require extending the language. If I was king of the world... oh, never mind. I think whichever one is simpler is probably the best choice :).

[alexcrichton]

Through cargo we ended up developing include!(concat!(env!("FOO"), "/bar")) which I think suffices for now as at least "a way." We can add a follow-up issue if we'd like to modify #[path].