Questions about Git-Gui Makefile and GNU File Name and Text Functions

Edua Vioz· Jun 3, 2020, 07:56 UTC · lore

Hey all,

Sorry to bother you for something that might turn out to be trivial, but I'm curious as to something I experienced when building git-gui with its current master branch's Makefile via Git Bash on Windows.

Essentially, the DEST value appeared to have suddenly changed mid-installation: It omitted the word "Program" from "Program Files" and failed to eliminate "libexec" from the target directory it ended up writing to (judging from the files installed by Git for Windows' installer, I assume it should be trying to place the share folder and its contents in the mingw64 folder). I've been poring over the Makefile trying to figure out the problem, and I have a few questions (aside from wishing to see some sort of public Regex-like sandbox tool sometime in the future that would let people preview the outcomes of File Name and Text Functions fed to them):

Would the outcome of $(dir C:/Program Files/Git/mingw64/libexec/git-core) be "C:/Program Files/Git/mingw64/libexec/" or "C:/ Files/Git/mingw64/libexec/"? If the latter, is there no way for the $(dir) File Name function to be told to respect white-spaces in files' directories? The way the Git Gui Makefile is set up, it's already passing the git --exec-path as a defined variable, so I'm guessing doing that's a no go. Is there a text function that can actually detect white spaces and substitute them in and out for ?\s for the sake of other functions that need them, for example?

Additionally, would $(notdir C:/Program Files/Git/mingw64/libexec/git-core) result in "Program git-core"? Which would then cause an ifeq against "git-core" to fail? Should I have been more panicked if the above code had actually let files be installed to "C:Program Files/Git/mingw64/libexec/git-core/share/git-gui/lib"?

I'm not really asking for a solution for myself: I'm pretty sure I can just change the Makefile so that I can successfully build Git Gui. I'm just curious if it's just been this long since a Windows user decided to take "you just need the dependencies installed and then you can make install" on the README.md at face value, did so, and then realized "oh, wait, I can't just do that."

Anyway, cheers all. I hope you're well, and I look forward to maybe hearing from you.

~ ElTipejoLoco

Paul Smith· Jun 3, 2020, 14:34 UTC · re: Edua Vioz · lore

Re: Questions about Git-Gui Makefile and GNU File Name and Text Functions

On Wed, 2020-06-03 at 02:56 -0500, Edua Vioz wrote:

> Would the outcome of $(dir C:/Program
> Files/Git/mingw64/libexec/git-core) be "C:/Program
> Files/Git/mingw64/libexec/" or "C:/ Files/Git/mingw64/libexec/"?

I'm not super-familiar with the Git build system so maybe there are mitigations for this there but: GNU make always treats whitespace as a word separator so it will apply the "dir" function to each word. So:

  $(dir C:/Program Files/Git/mingw64/libexec/git-core)

is equivalent to writing:

  $(dir C:/Program) $(dir Files/Git/mingw64/libexec/git-core)

and the expected result is:

  C:/ Files/Git/mingw64/libexec

> If the latter, is there no way for the $(dir) File Name function to
> be told to respect white-spaces in files' directories?

No. Make in general, and GNU make in particular, doesn't expect to be given paths with whitespace in them.

Again I'm not an expert in the Git build system but my understanding is that the install can be relocatable: in that case I recommend you build it into a location where there is no whitespace in the path, then move it wherever you like after building.

> Additionally, would $(notdir C:/Program
> Files/Git/mingw64/libexec/git-core) result in "Program git-core"?

Yes.  All GNU make functions work the same way.