Apache OpenOffice (AOO) Bugzilla – Issue 67145
APPxDEPN doesn't trigger build of dependency
Last modified: 2006-11-06 16:33:22 UTC
This problem (see attached logfile snippet) only occured once with a parallel build with MAXPROCESS=2. In automation/util the build of testtool.exe starts immediately without building the dependencies $(SHL2IMPLIBN) $(SHL3IMPLIBN) first. @ause: Any idea why this could happen? (A clean rebuild of automation didn't show the problem :( )
Created attachment 37597 [details] logfile from automation
Correction. automation builds fine with W32-tcsh in a non-parallel build, but with $ cd automation $ rm -rf wntmsci10.pro; build -- -P2 I can reproduce the problem every time.
Here is what I guess that's going on: in target.mk first _tg_app.mk is included that defines: $(APP1TARGETN): $(APP1OBJS) $(APP1LIBS) $(APP1RES) $(APP1ICON) $(APP1DEPN) $(USE_APP1DEF) <recipes> and APP1DEPN is defined to $(SHL2IMPLIBN) $(SHL3IMPLIBN) in automation/util *but* the SHLxIMPLIBN are defined in _tg_shl.mk (included after _tg_app.mk) so that at this moment they are still empty. The recipe lines are evaluated when the target is build, i.e. after all makefiles are read so that there is no problem with them. I'll try to create a testcase for my early evaluation theory, if this is true dmake should at least warn if a macro is (re-)defined after beeing used in a target definition.
Easy testcase: $ ./dmake/dmake.exe -rf t67145_1.mk echo all all --- t67145_1.mk --- SHELL*:=/bin/sh SHELLFLAGS*:=-ce all: $(NEWDEP) echo $@ NEWDEP=abc --- t67145_1.mk --- If NEWDEP would be evaluated at the time the target is build there should be an error that abc cannot be found and made. Actually this works as designed and can be worked around by using late evaluation using $$ instead of $, see dmake man page: DYNAMIC PREREQUISITES. But this should be said more clearly in the man page. So, the workaround for this problem is using $$, for the testcase this changes line 4 to: all: $$(NEWDEP)
urg, these is a bug in target.mk. fortunately it should be possible to swap these two includes. it's unlikely that a SHL target depends on a APP target. on the other hand, all those *nTARGETN, at least those i checked, should be defined with ":=" as all required information is present at that point. doing both shouldn't hurt... i'm not sure how to get this into 2.0.4 as vacation time is comming near and this change could require a bit of testing...
I don't see that using := for *nTARGETN would help here. The SHLxIMPLIBN are used as dependency for $(APPxTARGETN) (through $(APPxDEPN) ) but at this point (target rule definition of $(APPxTARGETN) in _tg_app.mk they are still empty. As you said, reshuffeling the order of the _tg_XXX.mk helps, but I would prefer "late evaluation" of the macros in target dependencies. As a minimal fix for this issue this would be (plus unrolling): +++ solenv/inc/tg_app.mk 10 Jul 2006 18:01:49 -0000 @@ -94,7 +94,7 @@ $(APP$(TNR)TARGETN): $(APP$(TNR)OBJS) $(APP$(TNR)LIBS) \ $(APP$(TNR)RES) \ - $(APP$(TNR)ICON) $(APP$(TNR)DEPN) $(USE_APP$(TNR)DEF) + $(APP$(TNR)ICON) $$(APP$(TNR)DEPN) $(USE_APP$(TNR)DEF) @echo ------------------------------ @echo Making: $@ .IF "$(GUI)"=="UNX" I'll test and add to vq34. Propably we'll find a few more issues with the "empty macros used patch" from issue 67166 and I'll create a CWS just for these warnings. But the QA can wait until you're back (who knows if it's even ready by then).
*@$%! Forget that patch. Unfortunately dmake treats empty macros in prerequisites with late evaluation as "", literally as the empty string. This leads to messages like this: dmake: Error: -- `' not found, and can't be made ERROR: Error 65280 occurred while making /cygdrive/d/w1/tin_ws/soltools/mkdepend ---* tg_merge.mk *---
Created attachment 37689 [details] patch for target.mk
The previous patch solves my parallel build problem on W32-tcsh. Committed to vq34. @ause: Please verify.
vq34 waits for verification of this issue now.
looks good, builds fine (as far as i can test it)
.