Unnecessary recompilation? #208

New Issue

cultab · 2022-12-21T15:18:18+02:00

cultab commented

2022-12-21 15:18:18 +02:00

This threw me off a bit, is this the expected behavior?

Behavior

$ make compiles the project.
$ make install attempts to install and obviously fails if $PREFIX is default.
# make install attempts to recompile and install.

Expected behavior

$ make compiles the project.
$ make install attempts to install and obviously fails if $PREFIX is default.
# make install uses binary from step 1 and install it.

This threw me off a bit, is this the expected behavior? # Behavior 1. `$ make` compiles the project. 1. `$ make install` attempts to install and obviously fails if `$PREFIX` is default. 1. `# make install` attempts to recompile and install. # Expected behavior 1. `$ make` compiles the project. 1. `$ make install` attempts to install and obviously fails if `$PREFIX` is default. 1. `# make install` uses binary from step 1 and install it.

Manos Pitsidianakis commented

2022-12-23 00:26:32 +02:00

I wasn't able to replicate this. I did

make
make install as non-root, failed because of default $PREFIX
make PREFIX=/tmp/ install worked without recompiling

I wasn't able to replicate this. I did - `make` - `make install` as non-root, failed because of default `$PREFIX` - `make PREFIX=/tmp/ install` worked without recompiling

cultab commented

2022-12-23 07:07:28 +02:00

Poster

The problem appers when running make install with root permitions e.g.
sudo make install .
With changing the PREFIX it works if the folder is user writeable.

The problem appers when running `make install` with root permitions e.g. `sudo make install` . With changing the PREFIX it works if the folder is user writeable.

Manos Pitsidianakis commented

2022-12-24 16:03:20 +02:00

Ah. Most probably you don't have the same cargo environment variables as the user and as root. So when you run with sudo, cargo rebuilds it because cargo home (usually $HOME/.cargo) is different. So it's expected behavior, because of the way cargo works and how the makefile target is defined. I think if the target was defined as the binary filename instead of a PHONY named target it wouldn't recompile it because Make would see it already exists.

Reference for cargo rebuild behavior: https://github.com/rust-lang/cargo/issues/10499

Ah. Most probably you don't have the same cargo environment variables as the user and as root. So when you run with sudo, cargo rebuilds it because cargo home (usually $HOME/.cargo) is different. So it's expected behavior, because of the way cargo works and how the makefile target is defined. I think if the target was defined as the binary filename instead of a PHONY named target it wouldn't recompile it because Make would see it already exists. Reference for cargo rebuild behavior: https://github.com/rust-lang/cargo/issues/10499

Manos Pitsidianakis closed this issue

2023-06-03 15:56:19 +03:00

Sign in to join this conversation.