git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Questions about Git-Gui Makefile and GNU File Name and Text Functions
@ 2020-06-03  7:56 Edua Vioz
  2020-06-03 14:34 ` Paul Smith
  0 siblings, 1 reply; 3+ messages in thread
From: Edua Vioz @ 2020-06-03  7:56 UTC (permalink / raw)
  To: git

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Questions about Git-Gui Makefile and GNU File Name and Text Functions
  2020-06-03  7:56 Questions about Git-Gui Makefile and GNU File Name and Text Functions Edua Vioz
@ 2020-06-03 14:34 ` Paul Smith
  0 siblings, 0 replies; 3+ messages in thread
From: Paul Smith @ 2020-06-03 14:34 UTC (permalink / raw)
  To: Edua Vioz, git

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.


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Questions about Git-Gui Makefile and GNU File Name and Text Functions
@ 2020-06-03 19:45 Edua Vioz
  0 siblings, 0 replies; 3+ messages in thread
From: Edua Vioz @ 2020-06-03 19:45 UTC (permalink / raw)
  To: paul; +Cc: eltipejoloco, git

On Wed, 2020-06-03 at 14:34 UTC, Paul Smith wrote:
>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

Yeah, I figured that was the case after skimming over GNU make
reference sites online and reading as much. Still, I figured I'd ask in case
Git or Git Bash specifically had been built to account for this in Git for
Windows, or if anything had changed since the documentation I'd read
had been written.

>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.

Ideally, yes. However, Git-Gui's Makefile was not written with this in mind.
It will append directories to DEST during installation that can (and do)
include drive letters. Again, the file can be modified to fix this on a case
by case basis, but ideally I wanted to learn if this was all already known
about this particular Makefile and if it was expected behavior.

I've actually already modified my copy of Git-Gui's Makefile to account
for whitespaces since I first wrote about it to the mailing list, but since I
suspect that it was automatically generated by software, I'd rather
learn if the tool responsible is open source and could be modified to
account for spaces in directory and file names instead of manually
fixing up every automated Makefile for each repository Windows users
come across until the tool is changed or no longer in use.

If I were to share it, should the patch by submit to a new e-mail thread,
or would it be fine to send it in as a reply to this one using the --in-reply-to
argument in git?

Thanks in advance for your time.

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2020-06-03 19:45 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-06-03  7:56 Questions about Git-Gui Makefile and GNU File Name and Text Functions Edua Vioz
2020-06-03 14:34 ` Paul Smith
2020-06-03 19:45 Edua Vioz

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).