Dual path/crates.io dependencies cause failures.

[retep998]

Some crates, in particular winapi, will have dependencies in the form of foo = { version = "0.2", path = "some/where" }. Building such crates from a git checkout is fine since all the path dependencies are in the repo and can be found. Building such crates from crates.io is also fine, since even though the other crates aren't in the archive, cargo will only use the versions from crates.io to build it and not the path dependencies. This pattern is useful as it allows rapid iteration of interdependent crates, while still allowing it to be uploaded to crates.io.

When built on crates.fyi, it is working with the archive downloaded from crates.io, and then attempts to build it with path dependencies, resulting in build failures as it looks for the other crates in locations that don't exist.

Some examples:
winapi and its failure.

Could not find `Cargo.toml` in `/home/updater/winapi-0.2.7/lib/runtimeobject`

kernel32 and its failure

INFO - LocalDependencyIoError(Error { repr: Os { code: 13, message: "Permission denied" } })

[onur]

Thanks for reporting.

The current version running on crates.fyi is really old (and new version is still not ready to replace old one). I've been trying to download crates directly from crates.io in the old version but it is using cargo to handle everything now. New version of cratesfyi is really similar to cargo subcommands.

You can see the new build log of kernel32 in here. But unfortunately cratesfyi is only working on x86_64-unknown-linux-gnu for now and documentation of windows only crates are not available. I have plans to add other platforms as well but there is currently no ETA.

You can follow new version progress in #12

[retep998]

I do hope you get windows documentation up eventually. If you need any help with Windows specific problems, feel free to get in touch with me.

[onur]

My experience is really limited on windows and the biggest problem is I have no idea how to make a secure sandbox for building crates. I need to find a way to protect file system and network from build.rs abuse.

[retep998]

There are three options:

1. Use something like sandboxie, which is basically the only good sandboxing application for Windows. It definitely will protect the filesystem, I'm not sure about the network though.
2. Do each build inside a virtual machine. This is the most secure option, but not the fastest.
3. Take advantage of the new experimental containers feature in Windows 10.

[nagisa]

You can generate documentation for arbitrary targets from arbitrary hosts, provided build.rs scripts aren’t doing weird stuff.

cargo doc --target=x86_64-pc-windows-msvc generated proper windows documentation for the libloading crate, which has build.rs and depends on other crates which also have build.rs.

[onur]

@nagisa this changes everything!

I just tried to build libc crate for different targets and it is building correct documentation for different targets. Thank you very much, I didn't know about this and I will definitely add "all targets" to cratesfyi now!

[onur]

Well looks like building every crate for every platform is gonna take at least 3 months. Maybe its better if I skip tier 2 and tier 3 platforms for the old version of crates.

[retep998]

Probably best to focus on tier 1 for now and worry about tier 2 and tier 3 later when there is spare computing power.

[onur]

I am closing this issue since it was only exists in old versions of cratesfyi.