Apache OpenOffice (AOO) Bugzilla – Issue 6656
Dependency list causes parallel make to fail
Last modified: 2013-08-07 15:35:14 UTC
The makefile in sw/source/filter uses phony dependencies for some targets that cause a parallel build in this directory to fail. There are 11 targets that depend on the same target.. ascii, basflt, excel, html, lotus, rtf, w4w, writer, ww1, ww8 and xml all depend on filt_1st. These targets all touch a unique file once completed, so it would be more appropriate if they all used the file touched by filt_1st to check if it has been built, rather than a phony target.
Can't add attachment at the moment b/c of internal server error.. so posting in here! --------------------------------------------------------------------- --- sw/source/filter/makefile.mk 2001/08/24 14:29:41 1.3 +++ sw/source/filter/makefile.mk 2002/07/30 06:59:03 @@ -68,6 +68,7 @@ PROJECTPCH=filt_pch PDBTARGET=filt_pch PROJECTPCHSOURCE=.\filt_1st\filt_pch +FILT1STDEPENDENCY=$(MISC)$/filt_1st.dpc .IF "$(CALLTARGETS)"=="filter" RC_SUBDIRS= @@ -140,7 +141,6 @@ .IF "$(RC_SUBDIRS)" == "" .IF "$(depend)" == "" filter: \ - filt_1st \ $(SWSUBDIRS) \ ALLTAR .ELSE @@ -178,15 +178,18 @@ $(SLB)$/%.lib : % @echo @ +# Needs to be made first... +# $(FILT1STDEPENDENCY) is touched when completed, will use this +# as a dependency for the others filt_1st .SETDIR=filt_1st: @echo $@ @$(MAKECMD) -d $(MFLAGS) $(dbutilx) $(CALLMACROS) -ascii .SETDIR=ascii: +ascii .SETDIR=ascii: $(FILT1STDEPENDENCY) @echo $@ @$(MAKECMD) -d $(MFLAGS) $(dbutilx) $(CALLMACROS) -basflt .SETDIR=basflt: +basflt .SETDIR=basflt: $(FILT1STDEPENDENCY) @echo $@ @$(MAKECMD) -d $(MFLAGS) $(dbutilx) $(CALLMACROS) @@ -194,19 +197,19 @@ @echo $@ @$(MAKECMD) -d $(MFLAGS) $(dbutilx) $(CALLMACROS) -excel .SETDIR=excel: +excel .SETDIR=excel: $(FILT1STDEPENDENCY) @echo $@ @$(MAKECMD) -d $(MFLAGS) $(dbutilx) $(CALLMACROS) -html .SETDIR=html: +html .SETDIR=html: $(FILT1STDEPENDENCY) @echo $@ @$(MAKECMD) -d $(MFLAGS) $(dbutilx) $(CALLMACROS) -lotus .SETDIR=lotus: +lotus .SETDIR=lotus: $(FILT1STDEPENDENCY) @echo $@ @$(MAKECMD) -d $(MFLAGS) $(dbutilx) $(CALLMACROS) -rtf .SETDIR=rtf: +rtf .SETDIR=rtf: $(FILT1STDEPENDENCY) @echo $@ @$(MAKECMD) -d $(MFLAGS) $(dbutilx) $(CALLMACROS) @@ -214,23 +217,23 @@ @echo $@ @$(MAKECMD) -d $(MFLAGS) $(dbutilx) $(CALLMACROS) -w4w .SETDIR=w4w: +w4w .SETDIR=w4w: $(FILT1STDEPENDENCY) @echo $@ @$(MAKECMD) -d $(MFLAGS) $(dbutilx) $(CALLMACROS) -writer .SETDIR=writer: +writer .SETDIR=writer: $(FILT1STDEPENDENCY) @echo $@ @$(MAKECMD) -d $(MFLAGS) $(dbutilx) $(CALLMACROS) -ww1 .SETDIR=ww1: +ww1 .SETDIR=ww1: $(FILT1STDEPENDENCY) @echo $@ @$(MAKECMD) -d $(MFLAGS) $(dbutilx) $(CALLMACROS) -ww8 .SETDIR=ww8: +ww8 .SETDIR=ww8: $(FILT1STDEPENDENCY) @echo $@ @$(MAKECMD) -d $(MFLAGS) $(dbutilx) $(CALLMACROS) -xml .SETDIR=xml: +xml .SETDIR=xml: $(FILT1STDEPENDENCY) @echo $@ @$(MAKECMD) -d $(MFLAGS) $(dbutilx) $(CALLMACROS) @@ -243,16 +246,4 @@ kill: del $(SLB)$/filter.lib - -ascii : filt_1st -basflt : filt_1st -excel : filt_1st -html : filt_1st -lotus : filt_1st -rtf : filt_1st -w4w : filt_1st -writer : filt_1st -ww1 : filt_1st -ww8 : filt_1st -xml : filt_1st -----------------------------------------------------------------------
sw owner - can you confirm?
I think this issue should have been assigned to tools in the first place. Sorry, my bad.
reassigning to owner of selected subcomponent (not a sw-thing)
comitted on SRX643_OO closing
Could this also be checked into OOO_STABLE_1_PORTS too please.
now also in OOO_STABLE_1 and OOO_STABLE_1_PORTS
As discussed with Armin, he thought these bug were closed, he sees all of them as verified.
Reopening as there are more makefiles like this in the sw module.
Created attachment 5150 [details] Patch for sw/source/core/makefile.mk
Created attachment 5151 [details] Patch for sw/source/filter/makefile.mk
Created attachment 5152 [details] Patch for sw/source/ui/makefile.mk
patches 5150/1/2 checked in on stable branch.
This is b0rken :( oo_1.0.2_src/sw/source/core$ dmake core_1st ------------- ------------------------------ Making: ../../unxlngi4.pro/misc/core_1st.dpc dmake subdmake=true depend=t ALLDPC dmake: makefile.mk: line 78: Error -- Include file ../../../inc/sw.mk, not found ---* RULES.MK *--- dmake: Error code 255, while making '../../unxlngi4.pro/misc/core_1st.dpc'
the dependencies are wrong: instead of $(MISC)$/ui_1st.dpc it has to be simply ui_1st . patched on cdelab25
Marin's fixes and a corrected sw/source/ui/makefile.mk are now on the stable branch.
This always worked fine for me, the reason I made this change is because it affected the parallel build only. I dont see how changing a dependency from a directory to an actual target file can make anything worse.... If anything it is an improvement! The error you are seeing Chris, (../../../../inc/sw.mk not found) should not have anything to do with the changes made to these files. If anything, the only error I can see coming out of my changes is: ERROR: dont know how to make $MISC)/core_1st.dpc I am re-opening this issue, as I don't think the current patches are correct. What I had initially was correct, and having directories as dependencies is incorrect, as the parallel build will surely fail. I would like the last change made reverted. If the dependencies were the problem, then why isn't this also aparent in: - sw/source/filter - sw/source/ui as well? The EXACT same changes were made there too....
> The error you are seeing Chris, (../../../../inc/sw.mk not found) should not have anything to do with the changes made to these files. The problem is due to .SETDIR. Here's a comment I wrote in a previous issue: -------------------- The use of .SETDIR is known to have problems. The ones I am aware of are inconsistent bahviour when calling sub makes with MAXPROCESS >1, and it is very confusing when trying to make dependency rules: foo : bar baz .SETDIR xxx : foo When trying to make foo, dmake will look for ./bar. When trying to make baz, it will look for xxx/bar, because of the .SETDIR in baz. -------------------- So the targets with .SETDIR in them were changing the working directory, which then meant that the relative path ../../../../inc/sw.mk was not found. > I dont see how changing a dependency from a directory to an actual target file can make anything worse.... If anything it is an improvement! As you see, the problem is that due to the .SETDIR directive, the file can't be found and dmake doesn't know how to make it properly. The directory name can't be found either, but at least dmake knows how to make it and runs the target instead of stopping the build with an error. > I am re-opening this issue, as I don't think the current patches are correct. Well, I'm not 100% sure that the use of .SETDIR in these makefiles can ever work properly in parallel makefiles, so I agree that it would be better to clean this up more. But the solution on STABLE_1 does work now, even if not optimal, so shall we retarget to 1.1? > If the dependencies were the problem, then why isn't this also aparent in: > - sw/source/filter > - sw/source/ui > as well? The EXACT same changes were made there too.... ...because the build BROKE so I didn't get any further than the first error message.
Chris, I know you have been playing around with parallel builds, I have yet to try the new changes out in a parallel build, but I doubt it will work, as dmake would barf on a parallel build with a directory as the dependency.. Can you tell me if you have tried this in a parallel build yet? It seems strange that it was all working up to now. Why wasn't this reported earlier as a problem (not pointing fingers, just curious) I will be able to try this out in a few days time, I will see how I go with the new changes, and post back here. George
OK, I've tested it, as it was before, and you are right Chris, I got the same error... So I added an extra level of depth, and it all works fine again, weather you build in parallel or not. Here are my patches created from the 1.0.3 tag. George
added keyword, and changed target
Created attachment 5666 [details] Patch for sw/source/filter/makefile.mk
Created attachment 5667 [details] Patch for sw/source/core/makefile.mk
Created attachment 5668 [details] Patch for sw/source/ui/makefile.mk
George: Thanks for taking a look at these. These look ok to me but I feel a bit out of my depth with the .SETDIR stuff. I haven't tried these in a parallel build yet and it will take a while before I have time to try again. Ause, could you have a look at this for us please and say if you think this is OK too?
i'm not sure that this patch is realy a clean solution as there is a dependency on "..$/$(MISC)$/core_1st.dpc" but i cannot see a target for this. either it's sattisfied or dmake will break. you may want to have a look at the changes made on the "cws_srx644_os8" branch as the according developers could be convinced to remove this fancy stuff at all. from what i know it should be possible to backport this to 1.0.x. don't get confused by the whole bunch of code changes to remove the remains of windows precompiled header files.
Hans, "..$/$(MISC)$/core_1st.dpc" is just a dependency file that gets created once the core_1st subdirectory is built. Each of those directories has one of these files that gets created once the subdirectory os built. This was my suggestion because I didn't want to propose anything drastic.
since this isn't an issue in OOo 1.1 any longer and i do not see negative impact on regular (single process) build -> approved.
-
accepting issue
re-assigning to Nick Blievers
Accepting...
Hello, I found that this Issue is targetted to 1.0.4. Can you please retargetting this issue since 1.0.4 is not planned. maybe to 1.1.1 ? and can you remove the keyword, since you already accept it ? Thanks
Changed target release
sw/source/core/makefile.mk is very different than it was in 1.0. Please update your patches. Retarget to 1.1.2.
set target to Ooo later, since nobody seems interested to do further work on this, please let me know, if this is not the case any more, I will set new target then.
the parts of the "sw" makefiles causing this issue are long time gone (SRX645 and SRC680).
.