GNOME Bugzilla – Bug 588848
Add configure option to specify X server location
Last modified: 2013-12-16 19:55:53 UTC
Since we don't want to build-depend on the entire X server stack for gdm, we currently apply a patch like --- gdm-2.26.1+git20090717/configure.ac 2009-07-17 09:34:50.000000000 +0200 +++ gdm-2.26.1+git20090717.new/configure.ac 2009-07-17 09:59:21.068953307 +0200 @@ -1109,9 +1109,9 @@ else # what to do, what to do, this is wrong, but this just sets the # defaults, perhaps this user is cross compiling or some such - X_PATH="/usr/bin/X11:/usr/X11R6/bin:/opt/X11R6/bin" - X_SERVER_PATH="/usr/X11R6/bin" - X_SERVER="/usr/X11R6/bin/X" + X_PATH="/usr/bin" + X_SERVER_PATH="/usr/bin" + X_SERVER="/usr/bin/X" X_CONFIG_OPTIONS="-audit 0" fi X.org installs into /usr/bin/ nowadays, /usr/bin/X11 and /usr/X11R6 are obsolete in the Linux world at least. Now, I understand that this might not be entirely appropriate for other OSes, so perhaps this could be made a configure option? Like --with-x-server-path=/usr/bin/X which determines X_SERVER_PATH. X_PATH and X_SERVER_PATH would then default to `basename $XSERVER`. Thanks for considering!
Created attachment 159722 [details] [review] Allow to override X server path This is the patch we use in Debian, it allows overriding the X server path in the environment.
I think it would be better to use a configure --with-xpath argument rather than passing in the value with an environment variable. That said, the old GDM allowed users to configure the Xserver in the daemon configuration. Some users may have more than one Xserver installed and may want the ability to specify which one to use. Should we add this configuration option back? That might be a better solution. Also, I think the new multi-seat work that will hopefully go into 2.32 will provide more configuration options for specifying how the Xserver is run. So, it might make sense to wait until that patch lands to determine what work is needed.
*** Bug 594438 has been marked as a duplicate of this bug. ***
Dup'd bug attempts to use pkg-config to determine the path.
Personally, I'd like to see both patches (this one and #594438) added, but that is conditional as to why you do not have the xorg-server.pc file on your system. Is that just the distro that you develop on, or common among all distros? Either one would be sufficient for my users. My argument for the second patch is simply that pkg-config is there to that specific job for us without having to maintain a list of common prefixes (not to mention the not so common ones that developers might use for isolated testing).
I've pushed the patch in comment 0 for now. I don't mind a --with-x-server-path option, but pkgconfig seems nicer long term. There's two big niggles with pkgconfig though: 1) X doesn't ship a .pc file upstream 2) That wouldn't solve the problem mentioned in comment 0 since they don't want X in their build roots.
Given the comment above, I think that pkgconfig can go out the window. I'll continue patching locally until 2.32. However, in the patch that was committed, there is the possibility of X_SERVER_PATH and X_SERVER being empty. No telling what end users might try and do with that. I would think that in most cases, it would be acceptable to check for empty values and if so, set them from X_PATH. I think that, in addition to setting X_PATH with a --with-x-{path|prefix} switch or similar, would make everyone happy. Are there any objections to the additional logic? Note, that doesn't cover --with-x-server-path, but I didn't see it mentioned until the last comment, is it needed also? ie: is there any reason that someone would use a different Xserver than the one in the path providing the headers?
Comment on attachment 159722 [details] [review] Allow to override X server path rejecting since i think we decided a configure argument is better than an environment variable.
Let's close this for now. If anyone wants to add the configure argument they can just post it to a new bug and we can apply it then.