![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
TMI: Finding external crates
May. 15th, 2013 07:26 pmThe remote-package-ID patch landed, so I'm on to teaching rustpkg how to find external crates.
Currently, if you include an extern mod directive at the top of a Rust file, like:
supposing foo lives in some arbitrary (non-system) directory like /home/tjc/quux/lib, you have to pass in a -L flag to rustc, like: -L /home/tjc/quux. That's so it knows where to find the foo library to link with.
But in rustpkg we're trying to make it possible for files to self-describe, and get away from compiler flags as much as possible. So rustpkg will, itself, scan files in the crate it's trying to build for extern mods and try to build their dependencies automatically. So far, it only looks in the same workspace that the package it's building is in, since it only knows about one workspace (the current directory). But once I implement RUST_PATH, that'll be a lot more powerful.
Even more so, the plan is to change the syntax of extern mod directives so they don't have to just name identifiers. So you'll be able to write:
Eventually, this will cause rustpkg to try to fetch the foo package from my repository on github and install it. The package can be referred to in the code with the short name foo, since the entire URL fragment isn't a valid Rust identifier.
So far, I've implemented the part where rustpkg scans for extern mods and builds the named packages and dependencies if possible. I'm working on getting it to pass the right directories to the rustc driver so as to actually find the resulting libraries.
Currently, if you include an extern mod directive at the top of a Rust file, like:
extern mod foo;
supposing foo lives in some arbitrary (non-system) directory like /home/tjc/quux/lib, you have to pass in a -L flag to rustc, like: -L /home/tjc/quux. That's so it knows where to find the foo library to link with.
But in rustpkg we're trying to make it possible for files to self-describe, and get away from compiler flags as much as possible. So rustpkg will, itself, scan files in the crate it's trying to build for extern mods and try to build their dependencies automatically. So far, it only looks in the same workspace that the package it's building is in, since it only knows about one workspace (the current directory). But once I implement RUST_PATH, that'll be a lot more powerful.
Even more so, the plan is to change the syntax of extern mod directives so they don't have to just name identifiers. So you'll be able to write:
extern mod foo = "github.com/catamorphism/foo";
Eventually, this will cause rustpkg to try to fetch the foo package from my repository on github and install it. The package can be referred to in the code with the short name foo, since the entire URL fragment isn't a valid Rust identifier.
So far, I've implemented the part where rustpkg scans for extern mods and builds the named packages and dependencies if possible. I'm working on getting it to pass the right directories to the rustc driver so as to actually find the resulting libraries.