From: Cesar Eduardo Barros <cesarb@cesarb.net>
Date: Sat, 28 May 2011 21:07:36 GMT
Subject: Re: [msysGit] [PATCH] Embed an application manifest on MinGW
Message-ID: <4DE16418.4020002@cesarb.net>
In-Reply-To: <alpine.DEB.1.00.1105282241510.11411@bonsai2>

Em 28-05-2011 17:44, Johannes Schindelin escreveu:
> On Sat, 28 May 2011, Cesar Eduardo Barros wrote:
>> [...]
>> @@ -1551,6 +1554,11 @@ ifdef USE_NED_ALLOCATOR
>>          COMPAT_OBJS += compat/nedmalloc/nedmalloc.o
>>   endif
>>
>> +ifdef APPLICATION_MANIFEST
>> +	# Cannot be in LIB_OBJS because it must always be linked in
>> +	RESOURCE_OBJS += compat/win32/resource.o
>> +endif
>> +
>>   ifdef GIT_TEST_CMP_USE_COPIED_CONTEXT
>>   	export GIT_TEST_CMP_USE_COPIED_CONTEXT
>>   endif
>> [...]
>>
>> -git$X: git.o $(BUILTIN_OBJS) $(GITLIBS)
>> +git$X: git.o $(BUILTIN_OBJS) $(RESOURCE_OBJS) $(GITLIBS)
>> [...]
>>
>> -git-%$X: %.o $(GITLIBS)
>> +git-%$X: %.o $(RESOURCE_OBJS) $(GITLIBS)
>> [...]
>
> Is it possible that adding the resource object to GITLIBS would reduce the
> patch and be "more correct", too?

I thought about it, but it felt wrong. It is not a library, it is an object.

Also, while adding it to GITLIBS would add the object to all the right 
rules (in fact, I did a search for GITLIBS to find all the places to add 
the new object to), I believe it would get the object linked twice in 
some of the rules (the ones which do a $(filter %.o,$^) would get it 
both from GITLIBS via the filter and from GITLIBS via $(LIBS) on the 
command line).

-- 
Cesar Eduardo Barros
cesarb@cesarb.net
cesar.barros@gmail.com