[libclc] use default paths with find_program when possible

[RossComputerGuy]

Patch pulled from NixOS/nixpkgs#336465

This PR removes NO_DEFAULT_PATH where possible, the flag prevents Nix from building libclc correctly.

[arsenm]

The nix build should probably migrate to using the non-standalone build

[arsenm]

Why does this need to find any binary? Can't it just use the imported targets from the find_package(LLVM) above?

[hvdijk]

At https://github.com/RossComputerGuy/llvm-project/blob/056e0f9b7c7b788ad0d85a1479000fd1af4f98ce/libclc/CMakeLists.txt#L100-L104 there is a check for missing tools. This check would not work if using the imported targets if LLVM CMake files are installed, but the binaries are missing, which because of the way LLVM is split in distros is something that can easily happen.

[hvdijk]

Apologies, but I'm having a bit of trouble understanding the scenario that this PR addresses. It looks like it's meant to handle the case where LLVM_TOOLS_BINARY_DIR does not contain the LLVM binaries, is that right? In that case, why can LLVM_TOOLS_BINARY_DIR not instead be set to a path that does contain the LLVM binaries?

[RossComputerGuy]

The nix build should probably migrate to using the non-standalone build

Nixpkgs has no intention of moving away from standalone builds.

[RossComputerGuy]

Apologies, but I'm having a bit of trouble understanding the scenario that this PR addresses.

Nixpkgs adds the tools being used to $PATH so find program needs to use path.

[arsenm]

Nixpkgs has no intention of moving away from standalone builds.

I encourage you to acquire that intention. IMO libclc should not support the standalone build, and this should be version locked to the exact compiler commit. It's compiler data, not a real library

[hvdijk]

Apologies, but I'm having a bit of trouble understanding the scenario that this PR addresses.

Nixpkgs adds the tools being used to $PATH so find program needs to use path.

This PR enables inadvertent errors on non-Nix systems though. When a specific LLVM path is used, and a binary is missing there, but a different binary with the same name is available in $PATH, we don't normally want that other binary to be used, it is quite possibly from a wrong version of LLVM. Right now, this is detected early at CMake time, and with this PR, it would no longer be.

If standalone builds continue to be used, could this be avoided by changing the Nixpkgs build to install symlinks to all needed tools in a single directory (possibly a temporary directory populated during the libclc build), and making that directory available as LLVM_TOOLS_BINARY_DIR?

[RossComputerGuy]

IMO libclc should not support the standalone build, and this should be version locked to the exact compiler commit.

So it should be built along with the core of LLVM? Also, we package LLVM per version per subproject.

could this be avoided by changing the Nixpkgs build to install symlinks to all needed tools in a single directory (possibly a temporary directory populated during the libclc build), and making that directory available as LLVM_TOOLS_BINARY_DIR?

Maybe, although that sounds a bit hacky.

[arsenm]

So it should be built along with the core of LLVM? Also, we package LLVM per version per subproject.

Yes, it should be built along with the core (but doesn't need to ship in the same package as the core).

[RossComputerGuy]

Yes, it should be built along with the core (but doesn't need to ship in the same package as the core).

Sounds good, I'll communicate with the other LLVM Nix maintainers and see if this is a good idea to fully go ahead on.

[frasercrmck]

Nixpkgs has no intention of moving away from standalone builds.

I encourage you to acquire that intention. IMO libclc should not support the standalone build, and this should be version locked to the exact compiler commit. It's compiler data, not a real library

I don't disagree. The standalone builds are never going to be well tested and imo are a considerable barrier to (confidently) improving libclc. I know we've discussed this in the past.

That said, I'm not sure what the best course of action is. Would we be best to deprecate standalone builds in the next release, then drop them afterwards? Do we need an RFC? Do we need documentation for users on how to find the "archived" standalone build support if they wanted it?