I have a proposal for changing the m-c build system as it relates to
comm-central which is kind of hacky, but probably less hacky than the
current mess.
Background: for several months, the mozilla-central and comm-central
build systems have shared parts of their logic yet retained a partial
duplication of logic which is proving increasingly difficult to
maintain, both in comm-central and in mozilla-central land. At this
point, everything in both comm-central and mozilla-central is completely
known to the mozilla-central moz.build, but comm-central retains its own
(stale) copy of the Makefile-based build system. This results in having
two "top" objdirs and two topsrcdirs, which is the cause of all sorts of
problems and ongoing bustages for comm-central.
The root of the problem is the twin-objdir issue. Trying to patch every
place that gets the objdir wrong has proven to be an exercise in pain
and frustration, and clearly doesn't scale. The best solution would be a
comm-central/mozilla-central merger, but as long as that option is
vetoed, we're stuck with some sort of hacky build system logic. Some
comments by glandium have caused me to propose a relatively hacky idea.
Idea:
1. Have a single, flat objdir. i.e., obj-tb has mail, mailnews, js,
toolkit, etc. as its descendants rather than mail, mailnews, and mozilla/.
2. Have $(topsrcdir) in Makefiles refer to mozilla-central's source
directory. This lets us eliminate the comm-central quasi-duplication of
the build system.
3. Have topsrcdir ('/') in moz.build and jar.mn files refer to
comm-central if it's a comm-central file.
Effectively, this ought to reduce nearly all of the problems of
supporting comm-central to merely needing the logic in the moz.build
reader to keep track of two topsrcdirs, along with maybe needing to emit
a real_topsrcdir in some makefiles and using that for jar.mn files. This
also makes it far easier to do radical changes to build system logic,
since the only effects on comm-central would be necessary moz.build
migrations or ontology changes, as opposed to trying to figure out how
much of rules.mk or config.mk need to be tweaked.
Feedback before I start putting too much effort in trying to make this
work for all situations?
--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist
_______________________________________________
dev-builds mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-builds
