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

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 14, 2020, 17:26 UTC
Message-ID: <xmqqo8ndxhof.fsf@gitster.c.googlers.com>
In-Reply-To: <20200814150214.GC9518@danh.dev>

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

Show 26 quoted lines

>> Thanks.  Perhaps something along this line (which is totally
>> untested), as the top-level Makefile already exports
>> NO_INSTALL_HARDLINKS to submakes?
>> 
>> 
>> 
>>  Makefile | 9 +++++++--
>>  1 file changed, 7 insertions(+), 2 deletions(-)
>> 
>> diff --git a/Makefile b/Makefile
>> index f10caedaa7..1cdbf8e504 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -44,6 +44,11 @@ endif
>>  ifndef INSTALL
>>  	INSTALL = install
>>  endif
>> +ifdef NO_INSTALL_HARDLINKS
>> +	LN = cp
>
> 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.