rustpkg: Test multi-crate packages

[catamorphism]

No description provided.

[catamorphism]

Sub-bug of #5677

[emberian]

triage bump

[catamorphism]

I think this will more-or-less fall out of #7879, but I'm still leaving this open as a reminder to make a test case.

[catamorphism]

It's actually not clear to me what the meaning is of a package with multiple crates, unless only one crate of each type (library or executable) is visible outside the package. So far, we've been assuming that a package ID unambiguously corresponds to a single crate. If different crates in the same package had different package IDs, they wouldn't be in the same package.

I propose the following rules:

1. In a package with multiple crates, only the library and executable crates at the top level (in the src/FOO directory where the package ID is FOO) are usable by crates that aren't in the same package.
2. rustpkg builds all crates in a given package, but only installs the two top-level crates.
3. Crates can only refer to other crates in the same package if those crates are in the same directory.

[catamorphism]

Finishing this is blocked on #9732 landing.

[catamorphism]

We discussed this in the meeting today. The conclusion was that rustpkg won't include special support for packages that need to install multiple crates. In the cases where it's needed, it will be possible to do so via a package script (pkg.rs). Otherwise, rustpkg will assume that any given package corresponds to a single executable crate that gets installed, and/or a single library crate that gets installed. (It will still build all crates when building a given package.)

[SiegeLord]

I think it would be very disruptive to be able to install multiple crates via pkg.rs, but not be able to reliably use those crates from other crates handled by rustpkg (i.e. via the extern mod = "pkgid" syntax). I propose two possible resolutions to that:

1. Keep current syntax, add a disambiguation attribute:

   extern mod foo = "Foo"; // Link crate Foo from package Foo, and rename it to foo
   
   #[crate(Bar)]
   extern mod foo = "Foo"; // Link crate Boo from package Foo, and rename it to foo

   Pros:

   • Backwards compatible

   Cons:

   • Awkward reading (a module is assigned to a package?)

2. Remove the current syntax, express everything as attributes:

   #[pkg("Foo")]
   extern mod foo; // Link crate Foo from package Foo, and rename it to foo
   #[pkg("Foo"), crate("Bar")]
   extern mod foo; // Link crate Bar from package Foo, and rename it to foo

   Pros:

   • Consistent positioning of package/crate specification
   • Less syntactic rules

   Cons:

   • Not backwards compatible
   • More syntactically heavy in the likely common case of "one package=one crate".

[catamorphism]

I closed #8952 as a dup of this bug, but I want to make sure to address it:

"

@bjz pointed out the following example with glfw:

https://gist.github.com/bjz/8aac0e5338f50b88e31c

The repository contains several subdirectories under examples/, each containing a main.rs, but rustpkg only leaves one executable (named examples) under build/. It should be creating a subdirectory of build/ for each of the examples/ subdirectories.
"

[flaper87]

Closing rustpkg is deprecated