Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Browse files
Browse the repository at this point in the history
patch 8.1.0215: no error if configure --with-x cannot configure X
Problem: No error if configure --with-x cannot configure X. Solution: Check that when --with-x is used X can be configured.
- Loading branch information
Showing
3 changed files
with
16 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
d2a0549
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@brammool:
This commit, as pulled downstream to Homebrew by Homebrew/homebrew-core#30881 (most of the time, Homebrew pulls new Vim releases down every 50th patch to prevent spamming the core tap, or package repository, with a large number of commits from the same upstream project,) has exposed that the Vim's
configure
script'sac_x_header_dirs
variable:vim/src/auto/configure
Lines 8101 to 8140 in af559d2
doesn't include anything referencing
/opt/X11
, the standard X11 prefix under the X11 distribution provided to users of OS X/macOS (Darwin) by the third-party XQuartz project.This makes the X include-/library-path detection code that follows overlook X headers and libraries from directories inside that location, leaving your
configure
script's X header and library search-path cache values empty. In the end, this causesbrew install vim
, when invoked with the relevant downstream build formula's, or recipe's,--with-client-server
option (which, as seen here, passes Vim'sconfigure
script its--with-x
option,) to fail. That downstream code could be fixed there to pass the correct--x-includes
and--x-libraries
options needed to cover this case, but I thought it might end up being a better idea to get this fixed upstream and then pull a new release down. I'd just submit a PR to add/opt/X11/include
toac_x_header_dirs
, but a first look at that part of the script suggests that doing that might only take care of looking up the location of X headers, but not libraries. I can open an issue for this if you'd prefer not to continue discussion here.(Previously, I suppose Vim's
configure
was just silently ignoring--with-x
in the case I describe here, which was why nobody had picked up on this issue before now…unless some older behavior handled things correctly and nobody noticed when they broke it…? 🤷♂️)d2a0549
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That shouldn't happen since, when XQuartz is installed successfully, it creates the file
/usr/X11
which is a symbolic link to/opt/X11
, so that the resulting installation will comply with the standard X11 installation which can be seen with other Unix systems. For instance, on my macOS, I haveand I've never experienced the failure you mentioned, though I'm not sure the details of it.
So the mentioned failure with Homebrew might come from other reasons and hence for further discussion, a concrete example of the failure would be helpful.
d2a0549
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nuko8:
Whoops, guess I overlooked that and/or forgot that happened. Maybe this is a Homebrew issue after all, then… In that case, I'll open an issue downstream (with logs attached, naturally) and CC you and @brammool on it.
d2a0549
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
d2a0549
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@brammool:
I didn't know it was, though, until this commit interacted with my build/installation environment to prove otherwise. (Previously, it failed silently, ignoring the problem and proceeding on without any other hiccups.)
I'd like to restore my current configuration (modulo updates) to full working order if at all possible. That is another solution, however, and is what I'll have to do if we can't resolve this issue (which, however, I doubt will be a problem.)
Agreed; hopefully this turns out to be simple like one would suspect.
See the second part of this reply.
I can take a look in a minute and see what's what.
d2a0549
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@brammool, @nuko8: Issue filed downstream as Homebrew/homebrew-core#30949.
d2a0549
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@brammool:
Sorry to keep you waiting; here's what those parts of my filesystem look like:
So it looks to me like everything's there. Maybe this is a(n) (downstream) issue with Homebrew's sandbox…? 🤔🤷♂️