Revert PR 201 "Expose internals to lib"

[japaric]

This reverts commit 9314804.

I'd rather not make this API public; it forces semver on us and we would have to bump the minor
version more often. For example, we would have to bump the minor version whenever we change the API
of generate::{interrupt,..,register}::render, which happens to be a pretty big API surface as it
includes structs from the svd and the syn crates so if we (minor version) bump any of those
dependencies then we have to bump the minor version of svd2rust as well.

Also the more often we bump minor versions the more work we give to device crate authors: now when
they re-generate their device crates they have to check if the minor version actually broke the
generated API or if it just was due to change in the API of svd2rust, the library.

If we want to expose some API to turn SVD files into Rust code in build scripts (which I think it's
a bad idea (*)) we should expose a single function that takes a string in (the SVD file) and
returns a string (the Rust code).

(*) It forces all your users (both direct and indirect) to (re-)build svd2rust (which
takes non trivial amount of time) for every one of their Cargo projects that depends on your
crate. And for no gain whatsoever because the output of svd2rust depends only on the input SVD and
not on the build environment (unlike say running bindgen on C headers installed in /usr) so it's
just a waste of CPU cycles. It's better to cache the output of svd2rust in the device crate, IMO.

r? @Emilgardis
cc @dfrankland

[Emilgardis]

This seems reasonable, I had forgot how tricky semver can be. Feel free to merge

@dfrankland would a simpler interface work for your use case? i.e single function taking fn(String) -> String

[pftbest]

Is svd2rust ever going to support generating multiple files? like a separate rs file for each peripheral or something like that. Or do we recommend using form for that?

[adamgreig]

@tones111 this will impact your plans for stm32-rs/stm32-rs#5

[tones111]

@japaric @adamgreig
A use case in support of generating code at build time is discussed at stm32-rs/stm32-rs#8

Can a crate specify a build dependency on a binary crate to ensure a specific version of that binary is available at build time? If so, then #202 is sufficient. Otherwise we would need the simpler interface described above.

[dfrankland]

@japaric @Emilgardis, I think that a simpler interface would be the best thing to do.

Essentially what I am doing inside my build.rs file is just converting the SVD file to source and writing to src/lib.rs. @japaric, I agree that crates shouldn't rebuild if they are a dependency, it's definitely unnecessary. I do think that committing the files generated by svd2rust to git is also not good (some are ~15MB+). I propose that the simple interface exposed by svd2rust's lib.rs should be used only pre-publish to generate source that is not committed to git nor rebuilt as a dependency.

Also, if build.rs can't be used to pre-publish only, tools like cargo-make could be used. Or, build.rs could have feature flags to prevent rebuilding, or even caching builds (example of features in diesel's build.rs).

[japaric]

I'm making a release that includes #206 so I'm landing this (already tested locally using svd2rust-regress).

The simple codegen interface can be added in a follow up PR.