Difference between revisions of "Documentation/Building Guide/Basic Concepts"
m (1 версия) |
|||
| Line 56: | Line 56: | ||
We find that sw depends on connectivity etc. These modules in turn depend on others creating a large complex dependancy tree. | We find that sw depends on connectivity etc. These modules in turn depend on others creating a large complex dependancy tree. | ||
| − | {{ | + | {{Note|For more information on modules, see: |
* [[Source code directories]] | * [[Source code directories]] | ||
* [[Module Build Order]] | * [[Module Build Order]] | ||
| Line 69: | Line 69: | ||
To avoid the need of a time-expensive complete re-build each time a change in the code is introduced, the developers are asked to introduce only ''binary compatible'' changes in the code unless the it is agreed with the project owner. This means that the changes made are of such a nature that no recompilation of further dependent modules become necessary (inserting a new, non-virtual method in a C++ class would be an example of such a binary compatible change). The office suite will then be re-compiled as a so-called ''respin build'' before the next 'master' s declared. A respin build obeys only weak dependencies, i.e. dependencies within a module. Using weak dependencies allows you to, for example, to modify a base library header file without needing to perform a full build. Since a respin build relies on binary compatible changes, modules can be build in parallel, and the build takes much less time (a few hours) in contrast to a full build. | To avoid the need of a time-expensive complete re-build each time a change in the code is introduced, the developers are asked to introduce only ''binary compatible'' changes in the code unless the it is agreed with the project owner. This means that the changes made are of such a nature that no recompilation of further dependent modules become necessary (inserting a new, non-virtual method in a C++ class would be an example of such a binary compatible change). The office suite will then be re-compiled as a so-called ''respin build'' before the next 'master' s declared. A respin build obeys only weak dependencies, i.e. dependencies within a module. Using weak dependencies allows you to, for example, to modify a base library header file without needing to perform a full build. Since a respin build relies on binary compatible changes, modules can be build in parallel, and the build takes much less time (a few hours) in contrast to a full build. | ||
| − | {{ | + | {{Note|By contrast, ''binary incompatible'' changes require a full build. For reasons of efficiency, this is allowed only with the approval of the project owner.}} |
=== Snapshots / Milestone Builds === | === Snapshots / Milestone Builds === | ||
| Line 89: | Line 89: | ||
When you want to build a specific project, you only need the sources of the relevant SVN modules and the output tree <code>solver</code>. You do not need the entire source tree, though typically a developer will check out one of the branches and build it from scratch. | When you want to build a specific project, you only need the sources of the relevant SVN modules and the output tree <code>solver</code>. You do not need the entire source tree, though typically a developer will check out one of the branches and build it from scratch. | ||
| − | {{ | + | {{Note|For more information on the solenv and solver trees, see the [http://tools.openoffice.org/ Tools] project.}} |
{{PDL1}} | {{PDL1}} | ||
Latest revision as of 16:58, 25 August 2011
To understand all concepts, techniques and the terminology described in this guide, make sure you understand the following basic concepts.
Contents
Terminology
| Term | Description |
|---|---|
| SRC_ROOT | The environment variable containing the path to the directory of the source code. Example: /home/john/projects/ooo/builds/OOO310_m11 |
Branches
Development branch (currently DEV300)
This is where most development is done. It has the most open policy for applying patches and it is typically where new features are developed and debugged.
The good side to this is that you have the latest features, the down side is that you get the side effects of the changes. We don't discourage you from working here, but you can might be problems at times (esp. if you work on the head revision and not on an milestone release by RelEng).
Developer releases are merged back to the stable branch on a semi-regular basis. All features migrated to the stable branch must be stable.
Stable branch (OOO3XX)
A stable branch is base for a release build of the OpenOffice.org product. This is where bug fix tracking takes place. The policy on these branches are to fix functional errors only.
The good side is that any patches are more thoroughly vetted before going into a stable release. Therefore you have fewer mystery bugs. The downside is that there are fewer features and some bug fixes are already in the developer release.
Porting branch
This is where a lot of porting to new platforms takes place. There are few features added in these branches and sometimes they are somewhat outdated in terms of functionality as a port needs some stability so that they are not solving new problems but working to an end goal together.
Features that are added are to help support that platform for example adding a new way of calling windowing functions for example coding Mac OS aqua calls instead of X windows calls.
This branch is used for platforms that are not yet part of the official release platforms, e.g. Irix and Linux s390.
Modules and Projects
The source code directory contains a lot of folders, each one representing a module. A module belongs to a project within the community, and provide an application, a function, or simply just a collection of classes. A module is the smallest unit of the office suite that can be built.
A project builds a particular component of the office suite. For example, the Writer project builds the Writer application. A project is an application, function, or simply a summary of classes. A project may be subdivided into modules, see above.
Modules correspond to the directories under the top-level directory of the source tree. For example, the Writer project includes the sw, starmath, res modules, etc.
There are many dependencies between the modules, and the modules must build in a particular order. Module prerequisites are described in first line of the file prj/build.lst for example:
froddo: /data2/office/sw/prj$ cat build.lst sw sw : connectivity svx stoc uui sch NULL
We find that sw depends on connectivity etc. These modules in turn depend on others creating a large complex dependancy tree.
 |
For more information on modules, see: |
Build Styles
Full Builds
OpenOffice.org developers typically perform a full build of OpenOffice.org in order to build their modules. A full build also recompiles all of the source code. It can take up to a few hours to perform a full build of OpenOffice.org even on modern workstations. Using tools such as distcc and ccache can have dramatic time improvements however.
Partial Compatible/Incompatible Builds
To avoid the need of a time-expensive complete re-build each time a change in the code is introduced, the developers are asked to introduce only binary compatible changes in the code unless the it is agreed with the project owner. This means that the changes made are of such a nature that no recompilation of further dependent modules become necessary (inserting a new, non-virtual method in a C++ class would be an example of such a binary compatible change). The office suite will then be re-compiled as a so-called respin build before the next 'master' s declared. A respin build obeys only weak dependencies, i.e. dependencies within a module. Using weak dependencies allows you to, for example, to modify a base library header file without needing to perform a full build. Since a respin build relies on binary compatible changes, modules can be build in parallel, and the build takes much less time (a few hours) in contrast to a full build.
|
By contrast, binary incompatible changes require a full build. For reasons of efficiency, this is allowed only with the approval of the project owner. |
Snapshots / Milestone Builds
OpenOffice.org is built and tested. Tarballs of the current source as well as solver and installation tarballs are published in the download page at www.openoffice.org. This happens roughly every four weeks. As a result, a snapshot of the current state of OpenOffice.org is available. In case the snapshot contains some outstanding 'milestone' improvements in functionality or coding, we may also refer to the snapshot as a milestone build.
Source and Output Trees
OpenOffice.org developers work in parallel on all platforms. The source code for all platforms is identical, with the exception of the code for the interface to the operating system and window managers. This allows you to build for the different platforms simultaneously from a single source tree, i.e. the directory structure that stores all of the source code for the office suite.
The solenv tree contains the environment tools that the build process uses, for all supported platforms. Formerly it also included the platform-specific build tools. Now these build tools are created with a bootstrap script created with the configure script.
When building multiple modules, these steps are taken for each module:
- The build process generates files from the source tree into the output tree of the module (this is a directory named after the platform, e.g. unxlngi6.pro for 32-bit Linux)
- After the module has been build, the results are copied to the solver, a directory sitting next to the top-level modules in the
SRC_ROOT. This step is calleddeliver(there is a tool with the same name). Modules cannot link/compile against the output directory of other modules, they only compile/link against objects in the solver.
When you run bootstrap, the solver directory is created. Initially, the solver directory is empty. The build process populates this directory. The build process delivers all binary files, shared libraries, and dynamic link libraries to solver.
When you want to build a specific project, you only need the sources of the relevant SVN modules and the output tree solver. You do not need the entire source tree, though typically a developer will check out one of the branches and build it from scratch.
|
For more information on the solenv and solver trees, see the Tools project. |
| Content on this page is licensed under the Public Documentation License (PDL). |
