Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
Summary: | Dependency list causes parallel make to fail | ||
---|---|---|---|
Product: | Build Tools | Reporter: | Unknown <non-migrated> |
Component: | code | Assignee: | nickb |
Status: | CLOSED FIXED | QA Contact: | issues@tools <issues> |
Severity: | Trivial | ||
Priority: | P4 | CC: | issues |
Version: | current | ||
Target Milestone: | --- | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Latest Confirmation in: | --- |
Developer Difficulty: | --- | ||
Issue Depends on: | |||
Issue Blocks: | 9443 | ||
Attachments: |
Description
Unknown
2002-07-31 02:37:44 UTC
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. 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). . |