[BUG] running "make" does a debug build but also installs to /usr

[anderslanglands]

To Reproduce

~/code/spk on  main! ⌚ 12:32:49
$ make
make debug CRATES=spfs,spfs-cli-main,spfs-cli-clean,spfs-cli-enter,spfs-cli-join,spfs-cli-render,spfs-cli-fuse,spfs-cli-monitor
make[1]: Entering directory '/home/anders/code/spk'
cargo build -p=spfs -p=spfs-cli-main -p=spfs-cli-clean -p=spfs-cli-enter -p=spfs-cli-join -p=spfs-cli-render -p=spfs-cli-fuse -p=spfs-cli-monitor
   Compiling proc-macro2 v1.0.78
   Compiling unicode-ident v1.0.12
  
   # ... snip ...

    Finished `dev` profile [unoptimized + debuginfo] target(s) in 51.43s
make[1]: Leaving directory '/home/anders/code/spk'
mkdir -p '/usr/local/bin'
for bin in target/debug/spfs*; do sudo install -p -m 755 $bin '/usr/local/bin'; done
[sudo] password for anders:
sudo setcap 'cap_dac_override,cap_fowner+ep' '/usr/local/bin/spfs-clean'
sudo setcap 'cap_net_admin+ep' '/usr/local/bin/spfs-monitor'
sudo setcap 'cap_chown,cap_fowner+ep' '/usr/local/bin/spfs-render'
sudo setcap 'cap_sys_chroot,cap_sys_admin+ep' '/usr/local/bin/spfs-join'
sudo setcap 'cap_dac_override,cap_setuid,cap_chown,cap_mknod,cap_sys_admin,cap_fowner+ep' '/usr/local/bin/spfs-enter'
sudo setcap 'cap_sys_admin+ep' '/usr/local/bin/spfs-fuse'

Expected behavior
Would assume debug build is done by default. Would definitely not expect it to install stuff to /usr

[rydrman]

Makes sense to me, I think at some point our default target got mixed up with the installation because I don't remember this being the case in the past. Should be easy to change the default target to just depend on the build instead of the install - I guess the only possible downside is that the debug build on it's own is not particularly useful unless you just want spk and already have a version of spfs installed to power it

[anderslanglands]

What's your normal development flow here? make install rebuilds the whole world. How are you making iterative changes during development?

[rydrman]

I can't speak for everyone, but I will typically use make test CRATES=<name,> to run unit tests on the crate(s) in which I'm working. Once I'm happy with the codebase I'll use make install to put things in place for final validation by hand - if it seems necessary. Alternatively, if I'm only working on spk changes I can usually use cargo run --bin spk just fine as the interactions between spk and spfs don't change very often these days