Documentation/Building Guide/Building on MacOSX/Some Background
What are CWS, EIS, VCL ...
Changes to OpenOffice.org are managed by a concept called ChildWorkSpaces which is abbreviated as CWS. The idea is to split changes into smaller and independent units to make testing, development, tracking easier.
OpenOffice sources are basically kept in the CVS server located at anoncvs.services.openoffice.org. However this repository is managed by a database on top called EIS (Environment Information System) which is used to keep track of Master- and Client Workspaces. Master Workspaces are used to keep track of changes going back of the mainline trunk and undergo extensive QA-cycles. These Master Workspaces are driven to official releases. Child workspaces in contrast are copies of certain Master Workspaces used to develop and test bugfixes and additional functionality. These Child Workspaces are later (hopefully) merged back to mainline Master Workspaces. The TX20 Report mentioned in the Links section gives a very good overview about the overall process. To learn more about Childworkspaces (CWS) have a look here: CWS.
Go to EIS http://eis.services.openoffice.org/EIS2/servlet/Logon and Logon as guest/guest to get yourself an impression. You can find information about the different workspaces, their dates and times there.
VCL (Visual Class Libraries)
Porting OpenOffice.org to a new Windowing Toolkit is mostly porting of the OpenOffice's VCL Layer (Visual Class Libraries) to the new platforms toolkit. The VCL-Layer is responsible for mapping the OpenOffice Application calls to the windowing toolkit.
The (native) OpenOffice port to MacOSX using the Aqua Windowing Toolkit is developed in a child workspace called aquavcl01. This child workspace consists of the modules (aka subdirs): canvas dtrans extensions freetype padmin scp2 sj2 solenv vcl.
The basic approach to prepare a developer's client system to successfully build OpenOffice/Aqua is the following:
- checkout a given OpenOffice Milestone.
- checkout aquavcl01 Child Workspace.
- merge them together.
- apply the latest patches.
The last point here is a cumbersome but nevertheless necessary operation, since this porting project is in flux. Thanks to Pavel and many others improvements are happening at tremendous pace at the moment. All of these improvements get distributed as patches/diffs against aquavcl01. Aquavcl01 needs to remain stable all the time, therefore the team needs to work on this patch-by-patch approach at the moment.