Calendar:Deprecated:Build System
There are four 'flavours' of calendar living in one tree. xpi-for-suite, xpi-for-toolkit-apps, lightning and sunbird. A lot of code is shared, but not all. The current build-system is a bit painful, because it isn't really possible to not share code. Sunbird works around it by overwriting files in the jar, and lightning copies a lot. Pain.
To get a better system, I suggest a calendar/base/resources for shared files. this would produce a calendar-base.jar. Non-shared files will live in a seperate dir per app.
Things to pay attention to:
- .css files. There must be a split between theme issues and things like -moz-box-orient, which is more content-like
- minimize the amount of forked files, for example by splitting the unifinder out of calendar.xul, so calendar.xul can be forked.
To get there:
In general: move things ready to be shared into calendar-base
- Move files that obviously should be shared into base. This would be the event dialog, the server properties etc.
- Move files that are not shared into a dir per app. This would be the about screens etc
- Try to use overlays to minimize needed forks. For example, the default would assume toolkit, with <toolbarpalette> and everything. This can be overlayed for xpfe into something that works there.
OR
Another possible route is to say there are only two flavours: fullwindow and lightning. the fullwindow version can come as xpi or sunbird, but the main window is the same. Maybe we should split based on that. (And either hope seamonkey switches to toolkit in the not too distant future, do smart things using overlays and javascript, or just drop seamonkey support)
