Have a "facade" top-level crate with Cargo features for CEF and Gonk

[SimonSapin]

Currently we have three "top-level" crates, each with their (largely duplicated) Cargo.lock file and target directory: components/servo, ports/cef, and ports/gonk.

Could we take advantage of Cargo features instead, to switch between these kinds of builds? That way we could have a single top-level crate (and so a single, shared Cargo.lock file and target directory). Maybe it would be a "facade" crate that mostly contains pub use re-exports conditioned by #[cfg] attributes.

CC @larsbergstrom

[pcwalton]

Even better, we could remove gonk and servo in favor of the CEF port, and use the CEF port as the facade.

[SimonSapin]

That would require writing two CEF “clients” that don’t exist yet, right?

[pcwalton]

Yes, but hopefully they'd be pretty similar if not identical. CEF has a simple API for the common case of "open a full screen or windowed chromeless window displaying a URI", which I believe is all that components/servo and ports/gonk do.

[larsbergstrom]

I suspect we'll want to let clients choose whether to use CEF or the raw Rust embedding API directly, if their final binary is in Rust and they'd prefer not to do a bunch of C shimming. Certainly, gonk prefers that - https://github.com/servo/servo/wiki/Mozlandia-B2S#use-cef

[SimonSapin]

@bholley, you asked in https://github.com/servo/servo/wiki/Meeting-2016-01-04 about dealing with the build system to add a new build target. The precedent we have is CEF and Gonk, that each have their own top-level Cargo.toml file and therefore their own Cargo.lock file. I do not think you should repeat this. Instead, I’d rather stay with a single top-level crate (with it’s Cargo.toml and Cargo.lock files), and use Cargo’s "features" mechanism to make it do different things. Maybe leave components/servo mostly as it is (or rename it) and have a new top-level crate that only does conditional compilation.

(This is only my opinion, maybe other people have other ideas.)

@alexcrichton Can we change crate-type (executable vs dynamic lib vs static lib) based on Cargo features?

[SimonSapin]

CC @metajack (see previous comment)

[Manishearth]

Note that cargo-feature-specific deps don't get entries in the lockfile. We can circumvent that with version pinning in the toml.

[SimonSapin]

@Manishearth it looks like they do:

/tmp$ cargo new aa
/tmp$ cd aa
/tmp/aa$ $EDITOR Cargo.toml

[package]
name = "aa"
version = "0.1.0"
authors = []

[dependencies]
matches = {version = "*", optional = true}

[features]
foo = ["matches"]

/tmp/aa$ cargo build
    Updating registry `https://github.com/rust-lang/crates.io-index`
   Compiling aa v0.1.0 (file:///tmp/aa)
/tmp/aa$ cat Cargo.lock 
[root]
name = "aa"
version = "0.1.0"
dependencies = [
 "matches 0.1.2 (registry+https://github.com/rust-lang/crates.io-index)",
]

[[package]]
name = "matches"
version = "0.1.2"
source = "registry+https://github.com/rust-lang/crates.io-index"

/tmp/aa$ cargo build --features foo
   Compiling matches v0.1.2
   Compiling aa v0.1.0 (file:///tmp/aa)

[Manishearth]

Huh. Perhaps that got fixed then

[alexcrichton]

@SimonSapin unfortunately, no, the crate-type cannot change based on features

[larsbergstrom]

Now that cargo workspaces exist and we've moved to them, this is no longer relevant.