Installation on macOS not working

[isolated-matrix]

Hi there,

I am having an issue installing this program on my MacBook Pro M1 Max. What I have done is download the source files, unzip them, and then place them in my Applications folder. Then, I cd into the directory and write sudo make install into the command line. For some reason, however, I keep getting errors saying:

fatal: not a git repository (or any of the parent directories): .git
make: *** No rule to make target `target/release/pbqff', needed by `install'.  Stop.

I just took a look at the Makefile and, while I know almost nothing about programming, I noticed these lines:

TARGET =
ifeq (${DEBUG}, 1)
        TARGET += target/x86_64-unknown-linux-gnu/debug/pbqff
else
        TARGET += target/x86_64-unknown-linux-gnu/release/pbqff
endif

Does this imply that pbqff can only be installed on a Linux machine? Because I do have Rust installed, so I had assumed it would work regardless...

[ntBre]

Ah, thanks for the report! I need to update the installation instructions and/or the Makefile. I mostly use this Makefile for deploying pbqff to one of our clusters, which is why I hard-coded the Linux target. If you're not worried about the man page or qffbuddy, the easiest way to install pbqff is actually just cargo install --path . from the root of the repository. That will put the executable in your $HOME/.cargo/bin directory (unless your Rust install put that somewhere else). That also prevents you from needing to use sudo anywhere. If you do want the man page and/or qffbuddy, you can use modified versions of these commands from the Makefile:

sudo cp qffbuddy/qffbuddy.py /usr/bin/qffbuddy
sudo cp man/rpbqff.1 $MANDIR/pbqff.1

I'm not sure where man pages go on Mac, but for my Linux distro, I would substitute /usr/local/share/man/man1 for $MANDIR. Mac may also not have /usr/bin? So you can copy qffbuddy anywhere on your PATH. You can, of course, use qffbuddy, the man page, and even the pbqff executable (after running cargo build --release) directly from inside the repo without installing anything, but I like putting these in directories on my PATH for easier usage.

I've intentionally left out the --features vers part of the cargo command from the README and Makefile. Since you downloaded a zip file instead of cloning the repository, this feature will fail to build. That's also related to your fatal git error above, even though that is not actually fatal from Make's perspective. This is totally fine as the only thing this feature does is embed the git commit hash in the binary so you can get an accurate output from the --version flag.

[isolated-matrix]

Thanks for getting back to me so soon!

I've now cloned the repository directly from git and it started to compile successfully using the command sudo cargo install --features vers --path .

Unfortunately, I came up to another error when it began compiling the files. I think I have come across this error before, but I cannot remember where... The last lines of the output (including a few, I assume, successfully compiled entries) are:

   Compiling libgit2-sys v0.16.2+1.7.2
   Compiling clap_derive v4.5.8
   Compiling env_filter v0.1.0
   Compiling tensor v0.1.0 (https://github.com/ntBre/tensor#c58afe5b)
error[E0554]: `#![feature]` may not be used on the stable release channel
 --> /Users/***/.cargo/git/checkouts/tensor-d50b1c84aa8f4aa1/c58afe5/src/lib.rs:1:12
  |
1 | #![feature(test)]
  |            ^^^^

For more information about this error, try `rustc --explain E0554`.
error: could not compile `tensor` (lib) due to 1 previous error
warning: build failed, waiting for other jobs to finish...
error: failed to compile `pbqff v0.1.0 (/Applications/qffs/pbqff)`, intermediate artifacts can be found at `/Applications/qffs/pbqff/target`.
To reuse those artifacts with a future compilation, set the environment variable `CARGO_TARGET_DIR` to that path.

It seems there's something about the tensor library it doesn't like. Looking this error up, I found that it has something to do with the version of Rust that is used to install the program not being allowed to use certain features unless I use the nightly build of Rust (where all features are unlocked)...?

[ntBre]

Ah yeah, I always forget to mention that too. I got rid of the nightly features in pbqff, but I still use them in some of my other crates (tensor included). You can either change your default Rust install to nightly with rustup default nightly (assuming you installed Rust with rustup) or you can run the cargo commands with +nightly added. In this case cargo +nightly install --features vers --path . Both of those should install the nightly toolchain automatically if you don't have it already.

Let me know if this works, so I can update the README with the final, working command!

By the way, I think it's usually better not to run cargo with sudo. I see that you're in your /Applications directory, which I assume requires you to use sudo to modify any files. Apologies if you already know all this and are installing here on purpose, but I think cargo is also going to put the final binary in your $HOME/.cargo directory, regardless of where you compile it. Personally I would have cloned the repo somewhere in my normal user directory and run the build there without sudo.

[ntBre]

Thanks again for this issue! I just checked all of my uses of unstable features and was able to clean up almost all of them, at least for building the pbqff binary. I'm still using the very useful lazy_cell feature, but fortunately this has been stabilized and will be available in the next stable release in ~10 days! For now, your best bet is probably still to use the nightly toolchain (or the beta toolchain if you pull these new changes), but thanks to your report, after July 25th, pbqff should be able to build on the newest stable toolchain.

[isolated-matrix]

Thanks for all the work you've done! I did not install Rust through rustup, I did it through MacPorts. MacPorts doesn't have the ability to install rustup (although I think Homebrew does), so I'm stuck in that regard. Unfortunately, it looks like I can't use the +nightly command with cargo unless I installed with rustup:

xxx pbqff % cargo  +nightly install --features vers --path .
error: no such command: `+nightly`

    Cargo does not handle `+toolchain` directives.
    Did you mean to invoke `cargo` through `rustup` instead?

As far as I can tell, if I want to use rustup, I would have to install a duplicate of Rust on my computer so it recognises that I have it at all. To avoid that, I might wait until the 25th and try again then. Hopefully the Rust devs push the update to MacPorts (according to the Rust site, the current version is 1.79.0, but the MacPorts version is still 1.78.0)...

Sorry for the trouble!

P.S.: The reason I was compiling it in the /Applications/ folder is because I'm not sure where GitHub programs are 'normally' installed to (whether it's to /opt/ or /usr/local/ or some other directory), so I thought I would just install it where all my other applications are. Is there a conventional directory to install these kinds of codes?

Speaking of which, if the program is going to be installed in the working directory and in ~/.cargo/, once the program has been compiled should I delete one of the copies?

Also, just FYI, in Macs, manuals are saved to $MANPATH.

[ntBre]

Ah I see. That's a bit unfortunate about how out-of-date the MacPorts build is. One last thing I can try is cross-compiling a binary for you. I've been thinking about starting to do real GitHub releases anyway, and I know some projects provide binaries like that. Is that something you'd be interested in trying?

Feel free to ignore my comments on build directories. I think I'm unusually curious/interested/opinionated about this stuff!

I see what you mean about /Applications. My main point was mostly that it's usually nice to build packages/binaries somewhere that doesn't require sudo. For example, I have a clone directory in my home area, where I often clone projects from GitHub and then build them. Only after building would I try to put the resulting binary somewhere on my $PATH like /opt or /usr/local like you mentioned. It's not a big deal, but I think it can prevent any issues in the build process from causing bigger issues with sudo privileges.

I'm not really sure about the conventions on Mac, but on Linux, if I wanted a binary in my PATH, I would probably put it in /usr/bin, but I keep some chemistry codes in /opt and just refer to them as /opt/mopac, for example. In this case, cargo (possibly annoyingly) makes the choice for you and puts it in ~/.cargo/bin. That's actually why my Makefile has a different install recipe that just builds the binary and then links it into /usr/bin rather than copying/duplicating the binary into ~/.cargo as you note. That has the added benefit of updating automatically when you recompile since it's a symbolic link, but the command isn't nearly as terse as cargo install.

[isolated-matrix]

Sorry for not replying earlier, I have been doing a bit of investigation.

I spoke to a rep from Rust about updating the MacPorts version and, apparently, they don't actually maintain it themselves. It looks like there is an issue with updating Rust for MacPorts because the maintainers want to make sure it remains compatible with very old Mac releases (older than Rust officially supports). They sent me this link to the update pull request: https://github.com/macports/macports-ports/pull/24640

I am happy to test out a binary for you, if you like? Although I'm not sure how easy it might be to build for an ARM Mac if you don't have one... And I am happy to wait until Rust on MacPorts gets sorted out—there's no particular urgency at this stage.

/opt was where I was thinking of putting it, but I also wasn't sure if the paths were set during the compilation process. Sounds like a nice compilation system though.

[ntBre]

That's very interesting about the MacPorts Rust build!

Cross-compilation is supposed to be very straightforward with Rust, you just pass --target x86_64-apple-darwin to cargo, for example. However, I didn't realize that the Mac targets were only supported on MacOS. There are some kind of local build tools that Rust invokes under the hood that couldn't run on Linux. Fortunately, I found one of my wife's old MacBooks, and I've slowly been updating it and now installing the Mac developer tools on it. It's not an M1, but I'm curious to see if I can cross-compile for M1 at least from some Mac.

I'll upload the binaries (probably an x86 binary that I think you can run with Rosetta and also an ARM executable if cross-compiling works) here once I have them, if you want to try them out. No worries if not, I see that you said there's no urgency on your end. It has been an interesting exercise for me either way!

/opt should be totally fine. Outside of my poorly-written Makefile, I don't think cargo should set any paths during compilation, especially if you just run cargo build --release --features vers. That should just put the executable in target/release/pbqff, which should be safe to relocate.

[ntBre]

As it turns out, there's a very convenient action for building and uploading binaries with GitHub runners. This release should contain binaries you can run:

https://github.com/ntBre/pbqff/releases/tag/v0.0.1

I tested out the Linux one and also downloaded the Mac ones to check the output of file:

$ tar xzf pbqff-darwin-aarch64.tar.gz
$ file pbqff
pbqff: Mach-O 64-bit arm64 executable, flags:<NOUNDEFS|DYLDLINK|TWOLEVEL|PIE|HAS_TLV_DESCRIPTORS>

Let me know if you run into any issues.

[isolated-matrix]

The binary seems to be working (as far as I can tell). When I type in a few of the different flags (-v and -h) I get the appropriate responses, so that is a good sign! Thank you for all your help!

[ntBre]

Awesome, I'm glad to hear it! Thanks for opening the issue. I'll close it for now, but if you run into any other problems, feel free to re-open the issue or start a new one!