Does anyone know of a tailor impl that generates multiple target for a single file? I was thinking about Rust again the other day, and a single Cargo.toml can expand to multiple binaries. So the regular owned/unowned set difference isn't enough to know whether more targets need to be added.

If tailor worked in this case, what would be the result? the creation of individual target entries (in BUILD) for each unowned binary mentioned in Cargo.toml, or would it create a target generator to mop up any binaries that haven't already been explicitly accounted for?

If we involve target generators there isn't any need for anything beyond

cargo_package

which maps to zero-or-one libraries and zero-or-more binaries. Otherwise, I'd expect something like

cargo_package

followed by maybe one

library_crate

followed by any number of

binary_crate

.

The nascent JS backend does something vaguely similar with package scripts (a single package.json can have multiple scripts that are individually runnable). I don’t know exactly how it does it, but maybe there’s some breadcrumbs there in terms of prior discussions

Nice, thanks @broad-processor-92400! Scanned through it and it looks like goes with the TargetGenerator approach.

TBH I think Rust is a great example of where we shouldn't need explicit targets at all, or at least not usually

That isn't possible today, though, is it? We need some form of target to hook on

Less pointless boilerplate. We get feedback from users that it seems silly to have to generate a bunch of basically empty BUILD files just for scaffolding. It makes things unnecessarily heavyweight.

I see -- I'll trust your word when you say that. My experience is that Bazel's explicitness plus gazelle/buildifier helps catch mistakes in build configuration. But at least with my current approach of just wrapping Cargo, there's little to no gain of trying to be smart... With a smarter approach (actually doing rustc commands etc) the explicitness would maybe add some introspection to that process.

Pondering on the tension between the two models and the ideas behind the existing recommendation to explicitly put these boilerplate-y BUILD files. Coming into it, it seemed reasonable to have BUILD files in directories because in a mono-repo, functionality would tend to be organized approximately aligned with the tree structure (rather than aligned with the repos in a polyrepo world). My fable for the need of these files was that any directory and its subtree could be the whole world to a particular developer and their team, and the BUILD files in there represented their ability to control the aspects of what happens within their area of responsibility. Like if they wanted to skip mypy in here, or if they were defining which things are meaningful to

run

or

package

. If they have something defined in a lambda, they would define it in BUILD in their subdir, rather than have to register it in some global file or even a file in a parent dir. This is neither here or there, excuse the rambling ...

I think the discussion is interesting at least, but as I said - I think tangential. I guess

targets

as a concept would still exist with or without BUILD files, so finding a good structure is still important. FWIW I ended up trying the TargetGenerator approach and it looks a bit dumb for single-bin-crates, but works:

✦ ❯ cat examples/hello-world/src/main.rs
fn main() {
    println!("Hello, world!");
}

✦ ❯ cat examples/hello-world/BUILD
cargo_package(name="hello-world")

✦ ❯ pants package examples/hello-world#hello-world
00:02:03.45 [INFO] Wrote dist/examples.hello-world/hello-world

✦ ❯ dist/examples.hello-world/hello-world
Hello, world!

This is with pants-hosted rustup/toolchain building in a sandbox.