Re: [BUG] `make install' partly ignores `NO_INSTALL_HARDLINKS'

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 17, 2020, 16:40 UTC
Message-ID: <xmqq8sed445k.fsf@gitster.c.googlers.com>
In-Reply-To: <20200815011544.GB12363@danh.dev>

Đoàn Trần Công Danh  <congdanhqx@gmail.com> writes:

Show 32 quoted lines

> On 2020-08-14 10:26:24-0700, Junio C Hamano <gitster@pobox.com> wrote:
>> > Since both git-citool and git-gui will be installed into same
>> > directory "$(libexecdir)", I think it would make more sense to use:
>> >
>> > 	LN = ln -s
>> >
>> > here instead?
>> 
>> In the top-level Makefile, INSTALL_SYMLINKS make macro does exist,
>> but it is not exported to submakes.  If it were, something like
>> 
>>     ifdef INSTALL_SYMLINKS
>> 	LN = ln -s
>>     else
>>     ifdef NO_INSTALL_HARDLINKS
>> 	LN = cp
>>     else
>> 	LN = ln
>>     endif
>>     endif
>> 
>> might become possible, but you'd need to audit what is fed to $(LN)
>> at the locations the macro is used and make necessary adjustment
>> accordingly.  "cp A ../B" or "ln A ../B" will make a usable copy of
>> file A appear inside ../B directory, but "ln -s A ../B" will not,
>> and I didn't see if all uses of $(LN) was to give synonyms to what
>> is already installed, or some of them were truly installing from the
>> build location when I gave the "something along this line" example.
>
> Yes, the top-level Makefile seems to have a special branch for
> BUILT_INS, in which, we will create symlink for those builtin in
> libexecdr if NO_INSTALL_HARDLINKS is defined.

Did you mean pieces like this?

	for p in $(filter $(install_bindir_programs),$(BUILT_INS)); do \
		$(RM) "$$bindir/$$p" && \
		test -n "$(INSTALL_SYMLINKS)" && \
		ln -s "git$X" "$$bindir/$$p" || \
		{ test -z "$(NO_INSTALL_HARDLINKS)" && \
		  ln "$$bindir/git$X" "$$bindir/$$p" 2>/dev/null || \
		  ln -s "git$X" "$$bindir/$$p" 2>/dev/null || \
		  cp "$$bindir/git$X" "$$bindir/$$p" || exit; } \
	done && \

The symlinks happen ONLY when INSTALL_SYMLINKS is asked for. Not all filesystems support symbolic links, hardlinks never suffer from dangling link problem, and often they are cheaper.

> I was aiming for something like this to make git-gui a bit more
> consistent with top-level Git, with or without INSTALL_SYMLINKS
> exported:

So with or without optional INSTALL_SYMLINKS exported, what I gave you is what is the most consistent with the top-level, that is, if INSTALL_SYMLINKS is there, we do "ln -s". Otherwise, we check NO_INSTALL_HARDLINKS and we do either "ln" or "cp".