GNU make version

[Michael Stahl]

On 10/02/12 11:25, Bjoern Michaelsen wrote:
> Hi,
> 
> On Thu, Feb 09, 2012 at 09:23:56PM +0000, Michael Meeks wrote:
>> commit 6055a5df7b6e7452987a9584d10f436ca2d349fd
>> Author: Bjoern Michaelsen <bjoern.michaelsen at canonical.com>
>> Date:   Fri Oct 7 16:40:22 2011 +0200
>>
>>     no more gbuild loops: break early on nonexistent objects (this commit
>>     breaks multi-repo support)
>>
>> 	could it be this one ? that introduces a good few wildcards ? it's odd -
>> by the time we get to here:
> 
> That should be easy to find out: just comment out the lines added by that
> commit and see if it gets better. Those added lines should do nothing on a
> healthy build. However, if someone adds an nonexisting file to compile, they
> prevent make from looping endlessly, which is IIRC a sideeffect of

that commit can't be the reason because the wildcards added there are
for source files and mmeeks' output shows headers which are never added
directly by gb_LinkTarget_add_*Object.

> commit dfde3d1f8bd347c79b1f69ac9dac487229af6357
> Author: Michael Stahl <mst at openoffice.org>
> Date:   Fri Apr 15 17:27:07 2011 +0000
> 
>     gnumake4: #i117845#: LinkTarget.mk: refactor dep-files: [hg:371ab623e90d]
> 
> replacing of the ifneq ($(wildcard ...)) with an -include. If that is indeed the
> case, Id propose offhand:
> - get rid of the wildcard calls from 6055a5df7b6e7452987a9584d10f436ca2d349fd
> - use the wildcard again in dfde3d1f8bd347c79b1f69ac9dac487229af6357
>   (which is per link target and not per cxx file)
> 
> As everything with deps for dep generation is quite tricky, this might need
> some more thought though.

yeah, actually those wildcards you added sound like a brute-force
workaround to me, but i never could reliably reproduce the infinite loop
problem which you solved there (though i actually had it myself once),
so i don't know what else could fix it.