`make` succeeds, but `sudo make install` fails: `make: cargo: Command not found`

[avh-on1]

Steps to reproduce the issue:

Run rustup to get latest version of cargo and rustc (1.30.1).

git clone https://github.com/newsboat/newsboat.git

cd newsboat/

make

sudo make install

The last line fails with:
cargo build --verbose --release
make: cargo: Command not found
Makefile:99: recipe for target 'target/release/libnewsboat.a' failed
make: *** [target/release/libnewsboat.a] Error 127

Other info you think is relevant:

I'm on Debian 9 Stable.

I could probably get the Makefile to run by configuring rust/cargo to run with sudo, but I was advised on reddit that make install shouldn't invoke cargo if immediately preceded by a successful make.

[avh-on1]

It appears that $(NEWSBOATLIB_OUTPUT) is FORCEd, which makes it run cargo build on make install, even after make. Is there a reason this is here?

[coder543]

As an example, librsvg references the Rust files involved directly here to avoid using a .PHONY or FORCE target.

This one enumerates the source files at make time.

I see a few people recommending .PHONY targets and pushing the rebuild logic off to cargo, so maybe that's fine for building the binaries, but I'm not sure of an obvious way that this could work with make install depending on the build steps when using standard rustup.rs installations.

It's been awhile since I've had to write a Makefile, but isn't it normal to make the install: rule somehow only depend on the binary artifacts existing, rather than depending on the rules that would build the binaries? In that case, if the binaries exist, they will get installed, without invoking anything else. If the binaries are out of date, that's not usually make install's problem, that's the user's problem for not running make, from what I remember of make philosophy... I could be wrong.

[Minoru]

Hi!

Yeah, the intention was to push rebuild logic off to cargo, but I failed to consider how this will affect make install—sorry about that! I like the find src -type f approach the most reasonable, since it gives make the least amount of knowledge it needs to decide if cargo should be called. I'm not too eager to maintain yet another list of files (we already have three for C++ and we always forget to update them).

Thanks for raising the issue, @avh-on1, and thank you for good pointers, @coder543. I'll go add that find call now.