Closed Bug 17525 Opened 25 years ago Closed 16 years ago

build total order must satisfy dependency partial orders (was: mailnews builds compose before mime)

Categories

(SeaMonkey :: Build Config, defect)

All
Other
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: brendan, Unassigned)

Details

(Keywords: helpwanted)

So we have lots of dependencies, from .c to .h files, and from .h to .idl files. We need to make sure the build total order (order in which subdirs are built by makefiles above them, all the way to the top of the tree) satisfies all the little partial orders induced by cross-module dependencies. We've already said "no cycles, A <> B means you really have one module, A+B, or three A-C, B-C, and C where A>C and B>C (C comes before either A or B because they depend on it)." Mscott got burned by bad build order the other day, mailnews/mime is built after mailnews/compose, but idl in compose needs stuff (re-)generated from idl in mime, so mime should be built first. An incremental build would not show the problem, but a clobber one would. This bug is multi-level: first, for mscott to fix mime vs. compose order under mailnews on all platforms. Then for leaf and me (pls. reassign to me) to get it right when we move mime up to top-level. Thanks, /be
Hardware: PC → All
Assignee: mscott → brendan
Target Milestone: M1
In order to fix my build breakage last night, I had to make mime build before compose on Windows and Linux. So my part of this bug is done for now. Over to Brendan to keep track of for stage 2 after mime moves out of mailnews.
Status: NEW → ASSIGNED
Is Mac ok already, or does it need to be told to build mime before compose? /be
Target Milestone: M1 → M12
Summary: mailnews builds compose before mime, or build total order must satisfy dependency partial orders → build total order must satisfy dependency partial orders (was: mailnews builds compose before mime)
Target Milestone: M12 → M13
Target Milestone: M13 → M14
Not gonna make M13. /be
Apart from real problems such as mscott's, this bug is really asking for docs. I'll deal with that quickly (before sabbatical starts in earnest) for M14, but I'm pushing this to M16 so I can do some not-so-quick-and-dirty docs, and leaf and I can do queued-up CVS directory moves and renames, etc. /be
Target Milestone: M14 → M16
Ok, for some reason that I'm going to attribute to the hour, I attempted to remove a build phase by consolidating the libs phase into the exports phase. This is how I discovered that a) we have circular idl-related dependencies in xpcom and b) xpcom depends upon an idl from libpref. xpcom/base/nsAllocator.h includes (but doesn't use) nsIFactory.h which is generated from xpcom/components/nsIFactory.idl xpcom/components/nsComponentManagerUtils.h includes nsIEnumerator.idl which is generated from xpcom/ds/nsIEnumerator.idl and finally almost all of the xpcom/ds/*.idl files include nsISupports.idl, located in xpcom/base And xpcom/base/nsTraceRefcnt.cpp includes nsIPref.h So are we even concerned about intra-module cycles or should I just give up the hope of a single pass build after we drop down to 2 phase?
mass re-assign of all bugs where i was listed as the qa contact
QA Contact: cyeh → chofmann
cls, are we any closer by dint of your efforts? /be
Target Milestone: M16 → M18
I'm afraid not. We still have intra-module circular dependencies in at least xpcom & mailnews. And non-standalone xpcom still depends upon nsIPref.h (nsIPref.idl). I haven't checked on any other modules.
That is only a debug build that depends on prefs... As for mailnews, everything is dependant on the libmsgbaseutil.so, but we're not going to be able to solve that anytime soon..(maybe after beta2, maybe not) There may be some mime/compose/base dependancies as well, but I'm not sure we'll be able to solve those by Netscape's FCS
Moving out, milestone 20 will become a better Mozilla milestone soon. /be
Target Milestone: M18 → M20
Target Milestone: M20 → mozilla1.0
Target Milestone: mozilla1.0 → mozilla0.9.3
Target Milestone: mozilla0.9.3 → mozilla1.0
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 (you can query for this string to delete spam or retrieve the list of bugs I've moved)
Target Milestone: mozilla1.0 → mozilla1.0.1
Target Milestone: mozilla1.0.1 → mozilla1.1
I'm a lousy owner for this bug. cls, you want it? /be
Assignee: brendan → nobody
Status: ASSIGNED → NEW
Keywords: helpwanted
Target Milestone: mozilla1.1alpha → ---
Product: Browser → Seamonkey
Priority: P3 → --
QA Contact: chofmann → build-config
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.