Can't refer to raze dir as a workspace

[mfarrugi]

I would like to reference the vendored libs as @cargo//:libc, but cargo raze @// is rejected.

Is there another prefix or setup that would work?

[acmcarther]

Hmm..

This would work by adding a WORKSPACE file to the cargo directory.

The workspace prefix ("@//") is what is used within the vendor directory itself, so you wouldn't want @cargo//, since all paths there would be workspace-relative. Instead, you'd just want "//" (which may or may not be accepted by the CLI.

So, something like this:

In //cargo/WORKSPACE

workspace(name = "cargo")

Then, in a hypothetical build rule

//hypothetical/BUILD

rust_library(
  name = "hypothetical"
  deps = [
    "@cargo//:libc",
  ]
)

Can you give the above a try and let me know if that works?

[mfarrugi]

cli dies on both "@//" and "//", error: Bazel path "@//" should not end with /, you probably want "@/".

I'm using the version of raze from cargo install, which doesn't appear to be using "@//" relative prefixes in the generated BUILD files. I'll try from source at some point.

[acmcarther]

I was going to go patch the project to tolerate "//", but I have this cryptic comment in the test

    // Vendoring into root is a really annoying edge case, not supported for now.
    assert!(validate_workspace_prefix(Some("//".to_owned())).is_err());

Is nesting raze stuff under a directory acceptable for your immediate usecase?

$  tree
.
├── cargo
│   ├── raze
│   │   └── vendor
│   │       └── libc-0.0.0
│   └── WORKSPACE
└── WORKSPACE

with an invocation like

cargo raze //raze

from within the cargo directory.

I don't recall what the "annoying edge case" was, but I think it might be related to the fact that "/" cannot be trimmed from "//" without breaking things.

EDIT: "nesting cargo" -> "nesting raze stuff".

[mfarrugi]

Yes that works, thank you.

…

On Thu, Nov 16, 2017 at 7:53 PM, Alex McArther ***@***.***> wrote: I was going to go patch the project to tolerate "//", but I have this cryptic comment in the test // Vendoring into root is a really annoying edge case, not supported for now. assert!(validate_workspace_prefix(Some("//".to_owned())).is_err()); Is nesting cargo under a directory acceptable for your immediate usecase? $ tree . ├── cargo │ ├── raze │ │ └── vendor │ │ └── libc-0.0.0 │ └── WORKSPACE └── WORKSPACE with an invocation like cargo raze //raze from within the cargo directory. I don't recall what the "annoying edge case" was, but I think it might be related to the fact that "/" cannot be trimmed from "//" without breaking things. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#12 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACLjeNastXiktSe4a0XHl4cHEaVFD_Spks5s3NjtgaJpZM4Qebkg> .

[acmcarther]

This isn't actually fixed but I suspect that it isn't what people would be wanting to do. Instead, they'd probably be vendoring into something like //third_party/cargo.

Willing to reopen in google/cargo-raze as "support vendoring directly into root" or something like that. This is probably a prerequisite to a "nicer" kind of integration that supports re-export to crates.io.