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.michael...@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 <m...@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. _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice