Cloudef / wlc

High-level Wayland compositor library
MIT License
330 stars 58 forks source link

Findxwayland #97

Closed yacinehmito closed 8 years ago

yacinehmito commented 8 years ago

Hardcode Xwayland's path at compile time. Fall back to the previous behaviour (i.e. relying on system $PATH) if it fails at runtime.

This is needed to make wlc behave nicely on NixOs.

Cloudef commented 8 years ago

The second commit is sort of useless, since the FindXwayland is REQUIRED in cmake anyways. So Xwayland has to be found. This looks all right anyways. I'll test it later.

yacinehmito commented 8 years ago

It's true that it is redundant. This was just in case you'd want this checked at runtime. If the binary is downloaded from elsewhere and the path to Xwayland is not the same as the one at compile time, the application will crash.

Cloudef commented 8 years ago

I'm still having hard time understanding the use case for this. Is this just so you can have custom path set at compiletime for Xwayland, in case for some reason it's not set in PATH?

yacinehmito commented 8 years ago

This exactly.

Cloudef commented 8 years ago

And PATH can't be used because?

yacinehmito commented 8 years ago

Sway and Orbment are being packaged for NixOS and this distribution is very spare when putting things in the PATH. Basically, you only have in your path what you're going to use directly, as a user. Libraries and derived binaries are completely hidden. The real reason is to allow multiple versions of a same program to be installed easily on the same machine.

Currently, wlc is packaged using my fork, which uses Findxwayland and a couple of dirty changes to the CMake file that fixes https://github.com/Cloudef/wlc/pull/46.

Cloudef commented 8 years ago

I thought NixOS would do something more sane and modify the PATH when you run program so it will find the binaries for that version of the program without recompilation.

This PR is probably better suited as downstream patch. In wlc we always want to rely on PATH by doing execlp("Xwayland", ...) finding the program with cmake yields absolute path. So it would always try the hard coded path deduced compile-time before running the actual binary from PATH. I don't think in Nix you would want it to try the fallback (from PATH), but always use the hardcoded path. For non nix systems the hard coded is actually worse, since it could confuse / mess things up.

yacinehmito commented 8 years ago

Alright I'll do that. Thanks for the review.