Hard coded build script means ineffective watches when the file is in a non standard location

[alerque]

The location of build.rs to watch seems to be hard coded as the Cargo default:

bacon/src/mission.rs

Line 17 in 27060c8

static DEFAULT_WATCHES: &[&str] = &["src", "tests", "benches", "examples", "build.rs"];

This location is, however, configurable. I do so in most of my projects to group build tooling out of the way of the top level directory when possible:

[package]
build = "build-aux/build.rs"

This location is not watched, hence changes to the file do not trigger updates in bacon.

I would suggest the Cargo manifest actually be read and the value of build (if set), and fall back to the default if it is not set. There might even be a way to query the active value out of Cargo, but I don't know what it is. Somewhat unhelpfully cargo read-manifest buries the relevant info a bit. For example on my git-warp-time project that relocates the build script, the info ends up here:

$ cargo read-manifest | jq -r '.targets[] | select(.kind[0] == "custom-build") | .src_path'
/home/caleb/projects/git-warp-time/build-aux/build.rs

[Canop]

I would suggest the Cargo manifest actually be read and the value of build (if set)

I'll have a look.

In the meantime, do we agree that you can simply add watch = ["build-aux/build.rs"] to your jobs ?

[alerque]

In the meantime, do we agree that you can simply add watch = ["build-aux/build.rs"] to your jobs?

I haven't tried it yet, but possibly yes. Is that value additive? Or will I also have to list of everything else that will affect the build?

Even so it's still unexpected that the things Cargo knows about the source layout isn't taken into account.

[Canop]

It's additive. And you can use watch = ["build-aux"] if you want to react to changes of all files in build-aux.

Even so it's still unexpected that the things Cargo knows about the source layout isn't taken into account.

Last time I checked, there was no good solution in the rust ecosystem for getting the information regarding the project's metadata. As I'd rather not maintain that part myself I use cargo-metadata whose design isn't great.

I'll have a look regarding the build part in cargo-metadata when I find some time.

[alerque]

Fair enough, and thanks for the info.

Before I opened this issue I had a quick look at the source to see if this was something I could easily fix, but since I didn't see if/where the manifest was being read at all it wasn't obvious how to fix this.

Last time I checked, there was no good solution in the rust ecosystem for getting the information regarding the project's metadata.

Yes, this is an ongoing gripe of mine with Cargo. By itself it's a pretty capable tool and I grant it has decent UX. But it does not play nice with other build systems or tooling at all. Even though bacon isn't a build system it shares this issue of having to guess/reproduce what sources go into a build without much from Cargo to go on.

(And thanks for bacon, I love it!)