Calendar:Deprecated:Build System: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
There are four 'flavours' of calendar living in one tree. xpi-for-suite, xpi-for-toolkit-apps, lighning and thunderbird. 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. | There are four 'flavours' of calendar living in one tree. xpi-for-suite, xpi-for-toolkit-apps, lighning and thunderbird. 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, | 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: | 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 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 | # 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. | # 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. | ||
Revision as of 15:35, 17 April 2005
There are four 'flavours' of calendar living in one tree. xpi-for-suite, xpi-for-toolkit-apps, lighning and thunderbird. 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.