initial work for cargo doc for markdown

[steveklabnik]

The beginnings of #739

This handles the building of a docdirectory, but not cargo test yet.

Does this look like it's on the right track?

[rust-highfive]

r? @huonw

(rust_highfive has picked a reviewer for you, use r? to override)

[steveklabnik]

/cc @chriskrycho

[chriskrycho]

👍

One of the things I was thinking about with this was including the --markdown-css bit. Maybe pull it in from Cargo.toml? (Honestly, that was the biggest thing that was blocking me going on it, because I just didn't even know where to start on that.)

[alexcrichton]

Looks like it's mostly along the right lines to me, thanks @steveklabnik! Some thoughts:

• This may want to recurse deeply to probe copy the entire filesystem structure
• Executing rustdoc will want to be tweaked, but you can see examples when running doctests for cargo test
• Tests :)
• It may be worth putting this in the backend to get parallelized
• We'll probably want configuration keys for the project to do things like:
  • Change the root folder
  • Disable this functionality entirely
  • etc

[steveklabnik]

Great! I wanted to hear from you before I did more work, that all seems reasonable.

This may want to recurse deeply to probe copy the entire filesystem structure

Should I use the walkdir crate for this? I forget what Cargo's policies on including external crates is.

It may be worth putting this in the backend to get parallelized

I don't know enough about Cargo's architecture to know what this would look like, any pointers?

[alexcrichton]

Nah I'd just recurse manually, it should be a pretty simple recursive traversal.

For now I guess we can avoid parallelization, would be good to at least get the framework and tests written first. To land this, however, I think we may need that (and I can help)

[steveklabnik]

(and I can help)

That would be rad, if you have the time, since you know Cargo way better than me.

[alexcrichton]

Sure, let's get the main bulk of stuff set up first (e.g. get the interface and all the tests working), and then after that we can do all that.

Another reason I just thought of for using the parallelization backend is that it also tracks dirtiness by default (e.g. doesn't re-run rustdoc unless it needs to), which is likely desirable.

[steveklabnik]

Hm, I thought removing the unwraps would help here. Need to dig deeper.

[alexcrichton]

Closing due to inactivity, but feel free to reopen if this is filled out!