rustpkg: Test multi-crate packages #7240

Closed
catamorphism opened this Issue Jun 19, 2013 · 9 comments

4 participants

@catamorphism

No description provided.

@catamorphism

Sub-bug of #5677

@cmr
cmr commented Aug 5, 2013

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

@flaper87 flaper87 closed this Feb 13, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment