Difference between revisions of "Ooo-build"

From Apache OpenOffice Wiki
Jump to: navigation, search
 
(38 intermediate revisions by 12 users not shown)
Line 1: Line 1:
 
This collection of patches, artwork and build infrastructure exists solely as a reflection of the many problems encouraging reasonably responsive change up-stream. The process of change is painful for any organisation, the larger the more painful. However - the size of the problem is no excuse to not try; hence the evenutal aim is to remove the need for ooo-build by incrementally fixing the various problems.
 
This collection of patches, artwork and build infrastructure exists solely as a reflection of the many problems encouraging reasonably responsive change up-stream. The process of change is painful for any organisation, the larger the more painful. However - the size of the problem is no excuse to not try; hence the evenutal aim is to remove the need for ooo-build by incrementally fixing the various problems.
 +
 +
{{Note|This page has a long history. Information about more recent improvements (done / in progress) should be found at [[Community_Council/Project_Improvements | Community Council / Project Improvements]].}}
  
 
== About ooo-build ==
 
== About ooo-build ==
  
−
ooo-build arose from acute frustration with the bad-old days of OOo process before the [[CWS|Child Workspace]] concept was introduced, it is
+
ooo-build arose from acute frustration with the bad-old days of OOo process before the [[CWS|Child Workspace]] concept was introduced, it was
 
also fueled by a non-performant [[Infrastructure_Problems#CVS|CVS server]].
 
also fueled by a non-performant [[Infrastructure_Problems#CVS|CVS server]].
 +
Things have been further improved in the mean time, see the [[Development/OpenOffice.org_Building_Guide|Build guide]].
  
 
* [[ooo-build/bin]] - A description of the tools in bin/
 
* [[ooo-build/bin]] - A description of the tools in bin/
  
 +
== Checking out ==
 +
To check out trunk ooo-build from the fd.o git repository, run one of the following in the command line:
  
−
== Building ==
+
# anonymous access
 +
git clone git://anongit.freedesktop.org/git/ooo-build/ooo-build
 +
# if you have a freedesktop.org account
 +
git clone ssh://[username@]git.freedesktop.org/git/ooo-build/ooo-build
  
−
FIXME
+
If you need to work on a branch:
  
−
== Fixing ==
+
git checkout -b ooo-build-3-0-1 origin/ooo-build-3-0-1
  
−
FIXME
+
(see [http://freedesktop.org/wiki/Software/ooo-build/GettingIt fd.o wiki] for authoritative info)
−
=== Sample simple fixes ===
+
  
−
==== Win32 / configure auto-detection ====
+
== Making a patch on a set of files ==
  
−
We have a nice perl script 'oowintool' that does a rather better job of auto-detecting various system tools than up-stream, we should integrate it there - it makes the common case much easier. cf. the last point though.
+
ooo-build itself is in git - but as a set of patches, not the patched OOo sources themselves. Working with patches is unfortunately not too straightforward and needs some training; but you can use git to make some of the operations easier by creating a local git tracking of the patched OOo sources, like:
  
−
==== branding / artwork / splash bits ====
+
make patch.apply
 +
cd build/oooABC-mXY
 +
git init
 +
../../bin/create-gitignores.sh
 +
# if you want to track just the 'sc' project
 +
git add sc
 +
# or instead track everything
 +
git add .
 +
git commit -m "initial"
  
−
Many of the ooo-build patches are simply branding changes for other distros. Getting that up-stream plus a combination of selectable 'experimental' features would prolly remove the usefulness of ooo-build substantially
+
Now you can create a new patch like this:
−
for these people. Altenatively perhaps good docs and a <code>--with-splash=/tmp/foo.png --with-logo=/tmp/baa.bmp</code> might work nicely.
+
cd build/oooABC-mXY
 +
# create a branch for the development
 +
git checkout -b tempbranch
 +
# modify the file, eg sc/blah/bleh.cxx
 +
# and commit it
 +
git add sc/blah/bleh.cxx
 +
git commit
 +
# edit something else, commit, etc.
 +
# create the patch
 +
git diff --no-prefix master tempbranch > ../../patches/dev300/blah.diff
 +
# now switch back to master
 +
git checkout master
 +
# and add the patch to ../../patches/dev300/apply (as described below)
  
−
==== faster 1st time (packagers/developers) build ====
+
To update an existing patch, you'll probably want to do something like this:
 +
# create a temporary branch
 +
cd build/oooABC-mXY
 +
git checkout -b tempbranch
 +
# unapply the patch
 +
patch -p0 -R < ../../patches/dev300/blah.diff
 +
# commit the revert
 +
git commit -am revert
 +
# apply the patch again to be able to edit it
 +
patch -p0 < ../../patches/dev300/blah.diff
 +
# edit it, commit the changes
 +
# when you are happy, find the commit id of the 'revert' commit
 +
git log
 +
# generate the patch
 +
git diff --no-prefix id-of-the-revert-commit > ../../patches/dev300/blah.diff
 +
# switch back to master
 +
git checkout master
  
−
Dependency generation takes a huge chunk of CPU time - simply detecting a pristine build & exporting 'nodep=1' trivially saves a chunk of time - should get that up-stream.
+
To remove the git tracking :
 +
rm -rf .git
  
−
==== easier developer experience ====
+
You can also think of more fancy use of git, like having a master branch for applying the patches, and other branches to track history of development you are doing, or use it to actually edit existing patches, to merge patches, etc.
  
−
Trivial, built-in, automated use of the system malloc allocator checker (via linkoo &amp; source ooenv), also - by default disabling the (incredibly annoying) 'recover from crash' dialog stuff via a similar trivial environment variable patch: i#54275.
+
Some people prefer stacked git (stg) over plain git when juggling with patches, after the initial "git init; git add .; git commit -a" do a "stg init" - and read the nice manual page.
  
−
== Releasing ==
+
== Adding Patch ==
  
−
When there's a particularly good reason for a release, such as a distro needs a stable base or we want to do something potentially
+
One of the main ooo-build features is the ability to apply patches against the upstream sources. A patch can be added the following way:
−
disruptive, one of the core ooo-build hackers will follow something like this process:
+
  
−
* '''cvs update''' - get the latest everything
+
* propose a patch file name:
 +
** the file suffix ''.diff'' is required
 +
** the file name ''<theme>-short-fix-description.diff'' is suggested when there are more thematic patches, e.g. ''warnigns'', ''unittesting'', ''speed'' that are not put in any thematic directory
 +
** the file name ''<module>-short-fix-description.diff'' is suggested when the patch modifies only one source ''module'', e'g' ''vcl'', ''svx'', ''sd''
 +
** the file name cws-<name> should be used for CWS backports
 +
** the file name ''short-fix-description.diff'' is enough otherwise
 +
* create the patch in the format to be applied in the top source directory with ''-P0'', see the sample content:
 +
*:<pre>
 +
*:--- jvmfwk/plugins/sunmajor/pluginlib/gnujre.cxx.old    2007-08-10 17:32:26.0000
 +
*:+++ jvmfwk/plugins/sunmajor/pluginlib/gnujre.cxx        2007-08-16 22:40:42.0000
 +
*:@@ -78,6 +78,7 @@ char const* const* GnuInfo::getJavaExePa
 +
*:...
 +
*:</pre>
 +
*put the patch below ''ooo-build/patches/<group>''; most patches are located in the MWS specific directory. Some bigger groups of patches have their own thematic directory. For example:
 +
*:<pre>
 +
*:patches/src680/sc-save-split-view.diff
 +
*:patches/src680/warning-return-values-filter.diff
 +
*:
 +
*:patches/scsolver/scsolver-source-inc-basedlg-hxx.diff
 +
*:patches/scsolver/scsolver-source-inc-baselistener-hxx.diff
 +
*:</pre>
 +
* mention the patch in the ''apply'' file:
 +
**ooo-build allows to sort the patches into groups and apply them conditionaly '''by distributions'''. Therefore, each patch has to be mentioned in the '''right section''' in the ''apply'' file. This file is usually located in the MWS-specific directory, e.g. ''patches/src680/apply''.
 +
**the patch entry might look like:
 +
**: <pre>
 +
**: [ CalcFixes ]
 +
**:
 +
**: # Support Hungarian localized keywords for CELL and INFO functions.
 +
**: sc-celltrans-hungarian-keywords.diff, i#80299, kohei
 +
**: # Fix saving split-view information on 64-bit platforms.
 +
**: sc-save-split-view.diff, n#235131, i#81936, jonp</pre>
 +
**please do not forget to mention the '''issue numbers''' and the responsible '''developer name'''
 +
**note that the patches are applied in the order in which they are listed in the apply file. If there are some conflicts between the patches, it might be necessary to '''split a section''', for example:
 +
**:<pre>
 +
**: [ Fixes ]
 +
**:
 +
**: # make unzip command not ask when overwriting files
 +
**: unzip-command.diff, i#81087, fridrich
 +
**:
 +
**: [ CalcFixes ]
 +
**:
 +
**: #fix import filter for userforms with calc specific data ( rowsource )
 +
**: svx-filter-userform-rowsource.diff, i#73753
 +
**:
 +
**:[ Fixes ]
 +
**:
 +
**: # edit fields text displaying
 +
**: svx-sdrobjeditview-update-edit-area.diff, n#305205, rodo</pre>
  
−
* Read back through the ''ChangeLog'' and update the ''NEWS'' file for the release, summarizing and attributing the changes.
+
== Committing a Change ==
  
−
* edit ''configure.in'', bump the version in the '''AC_INIT''' line, incrementing the minor version eg. '''AC_INIT(ooo-build, X.Y.Z)'''
+
''Please see the [http://freedesktop.org/wiki/Software/ooo-build/GettingIt freedesktop.org wiki] for the authoritative info.''
  
−
* Add a line to any handy ''ChangeLogs'', so we can easily see where this happened in the flow:
+
In git, the [http://freedesktop.org/wiki/Software/ooo-build/GettingIt#committhechanges commits] happen locally.  To make them available on the server, you have to either [http://freedesktop.org/wiki/Software/ooo-build/GettingIt#pushthechanges push] them (if you have the freedesktop.org account), or [http://freedesktop.org/wiki/Software/ooo-build/GettingIt#mailthechanges mail] them (if not).
  
−
<pre>
+
# it is our first session, we have to clone the repository
−
    2019-13-33 Ned Squeers <ned@sqeers.com>
+
git clone ssh://[username@]git.freedesktop.org/git/ooo-build/ooo-build
 +
  # develop something, now commit it
 +
  git commit -a
 +
# continue developing, and commit it
 +
git commit -a
 +
# it is finished, patches apply, everything builds, let's check that we did not
 +
# forget uncommitted changes
 +
git status
 +
# looks fine, let's double check the diff
 +
git log -p
 +
# everything is perfect, let's push to the remote repository
 +
git push
 +
# oh, it failed! - somebody committed some changes in the meantime, let's update
 +
git pull -r
 +
# double check
 +
git log -p
 +
# everything is fine
 +
git push
  
−
            * Version X.Y.Z
+
The form of the commit message should be like the following:
−
</pre>
+
  
−
* '''./autogen.sh''' - this re-builds configure with the version in place; a distro must be specified eg. '''./autogen.sh --with-distro=SUSE'''
+
First line roughly describing the change.
 +
 +
Leave one empty line, and then follow with more detailed description
 +
what and why you changed. This is really important, because some
 +
of the git tools (like gitk, git log --pretty=oneline, git rebase
 +
--interactive, etc.) show just the first line. Also we don't have
 +
a ChangeLog any more, so git log is now your source of the information
 +
about the changes.
 +
 +
Please do not forget to mention the bugzilla numbers, like i#12345 or
 +
bnc#234567.
 +
 +
* file1: Did this and that.
 +
* file2: And something else here.
  
−
* '''make dist''' - this builds the archive containing everything.
+
== Releasing ==
  
−
* '''cvs commit''' - so what's there is what's there. If there was a collision you get to loop to the first stage here, but don't re-increment the number.
+
When there's a particularly good reason for a release, such as a distro needs a stable base or we want to do something potentially
 +
disruptive, one of the core ooo-build hackers will follow something like this process:
  
−
* '''cvs -z3 tag OOO_BUILD_X_Y_Z''' - this leaves a static tag so we can reproduce the build at any time and easily diff between releases.
+
* '''git pull -r''' - get the latest everything
  
−
* '''md5sum ooo-build-X.Y.Z.tar.gz > ooo-build-X.Y.Z.tar.gz.md5''' - so that users can do at least the basic consistency check
+
* do a test build and a smoke test to make sure that the last commits are fine; you could commit any fix if needed; you need not push it, though
  
−
* '''scp ooo-build-X.Y.Z.tar.gz* ooo@go-oo.org:/var/www/packages/<MWS_DIR>/''' - uploads the tarball and the .md5 file for the right Master Work Space, eg. SRC680
+
* read back through the ''git log'' and update the ''NEWS'' file for the release, summarizing and attributing the changes. See also below for ''"Tag vs. Push"''
  
−
* It's then customary to announce the release, see the template in ''doc/announce.txt'' - update all the ***s to the right versions, insert the contents of ''NEWS'', fire and forget.
+
* edit ''configure.in'', bump the version in the '''AC_INIT''' line, incrementing the minor version eg. '''AC_INIT(ooo-build, X.Y.Z)'''
−
 
+
−
== Branching ==
+
−
 
+
−
When there's a particularly good reason for a branch, such as a MWS is moved to the maintenace mode and we want open HEAD for further development, one of the core ooo-build hackers will follow something like this process:
+
−
 
+
−
* create the tags:
+
−
** '''cvs update''' or  '''cvs update -r OOO_BUILD_X_Y_Z'''- get the latest everything or a tagged sources
+
−
** '''cvs -z3 tag -b ooo-build-X-Y-Z''' - do the branch
+
−
** '''cvs tag OOO-BUILD-X-Y-Z-ANCHOR''' - this leaves a static tag so we can diff against it and see the branch specific changes
+
−
* make changes specific for the original tree (HEAD):
+
−
** '''cvs co ooo-build''' - get sources from the original tree
+
−
** if it is an important branch, such as for a minor OOo version, add a line to the message printed at the end of ''configure.in''. It might be something like:
+
−
**:<tt>ooo-build-X-Y-Z  branch for X.Y.Z</tt>
+
−
** add a line to any handy ''ChangeLogs'', so we can easily see where this happened in the flow. Of course, if you branched an older tag, you must put the comment into the right context. See below for a sample comment.
+
−
** '''cvs commit'''
+
−
* make changes specific for the branch:
+
−
** '''cvs co -r ooo-build-X-Y-Z''' - get sources from the branch
+
−
** modify the message printed at the end of ''configure.in''. It might be something like:
+
−
**:<tt>This is ooo-build-2-0-4 - the stable branch for the 2.0.4 release.<br>If you want to build something cool, unstable, and risky, use HEAD.</tt>
+
−
** add the same comment to the ''ChangeLog'' as in the original tree
+
−
** '''cvs commit'''
+
−
* it's then customary to announce the release
+
  
−
Sample comment:
+
* '''git commit -a''' - commit the changes with a handy comment, so we can roughly see where this happened in the flow:
  
 
<pre>
 
<pre>
−
2019-13-33 Ned Squeers  <ned@sqeers.com>
+
Released ooo-build-X.Y.Z (X.Y.Z-betaM)
  
−
    * Branched for X.Y.Z:                                                 
+
* version X.Y.Z (X.Y.Z-betaM)
−
          OOO-BUILD-X-Y-Z-ANCHOR - the anchor tag,                             
+
* tag OOO_BUILD_X_Y_Z
−
          ooo-build-2-0-4 - the branch.                                       
+
 
</pre>
 
</pre>
  
−
== Support for new MWS ==
+
* '''git tag -s OOO_BUILD_X_Y_Z''' - create a signed tag for the given release; it is IMPORTANT so that anyone could check out exactly these sources anytime later; note that we might need to push another version later, see below for ''"Tag vs. Push"''
  
−
== Support for final OOo version ==
+
* '''./autogen.sh''' - this re-builds configure with the version in place; a distro must be specified eg. '''./autogen.sh --with-distro=GoOoLinux'''
  
−
== Remaining unsolved issue summary ==
+
* '''make dist''' - this builds the archive containing everything.
  
−
A helpful summary of these is provided here in no particular order along with suggestions for improvement.
+
* '''md5sum ooo-build-X.Y.Z.tar.gz > ooo-build-X.Y.Z.tar.gz.md5''' - so that users can do at least the basic consistency check
−
Many of these are mercifully easy to fix, and should be fixed soon.
+
  
−
=== source handling ===
+
* '''scp ooo-build-X.Y.Z.tar.gz* ooweb@seagull.dreamhost.com:~/download.go-oo.org/<MWS_DIR>/''' - uploads the tarball and the .md5 file for the right Master Work Space, eg. OOO310
  
−
==== src packaging ====
+
* It's then customary to announce the release, see the template in ''doc/announce.txt'' - update all the ***s to the right versions, insert the contents of ''NEWS'', fire and forget.
  
−
We have habitually split the source into several pieces to aid downloading. The process of achieving this is codified in a
+
* '''git pull -r''' - get the last changes from the remote repository to be able to push the changes; this might cause reordering of the git log, see below  ''"Tag vs. Push"''
−
simple shell-script [[http://go-oo.org/ooo-build/bin/src-pack here]]. It is of course necessary to have source archives that include the CVS directories & information, (or perhaps split that out into another package - but yet make it available) - such that developers can easily 'cvs diff -u' to extract their changes, and of course tinderbox slaves can base off these archives.
+
  
−
==== src download ====
+
* '''git push --tags''' - push the changes, including the tag,  to the remote repository
  
−
ooo-build has a post-configure 'download' mechanism, whereby the relevant source archives will be automatically downloaded to your system having configured it, in response to your various options.
+
=== Tag vs. Push ===
  
−
=== cvs slowness ===
+
IMPORTANT:  You should always check out the tag or check the released tarball to make sure what changes are included.
  
−
It can take multiple hours to tag (once) the full up-stream CVS; this is not conducive to some of the more funky
+
We do the tag in the local git copy. We need to do '''git pull -r''' before '''git push --tags'''. It means that the recent changes in the remote repository will be moved before the last local changes. It means that there might be added some entries in the ''"git log"'' before the ''"Released ooo-build-X.Y.Z"'' entry. It means that the global ''"git log"'' does not mention correctly what changes are included in what release.
−
'nested workspace' ideas based on the [[CWS]] tooling becoming a reality. Adding large modules to a cws currently
+
−
takes way too long. Interestingly, it's can be quicker to do a $ cvs diff, create a new cws and apply the patch
+
−
than re-sync a cws. It also helps to have the diff in hand in case the cws tools fail mid-flow, since that has been known to loose data.
+
−
A 'diff -u' by contrast, or an anonymous diff from cvs - combined with ooo-build's intelligent patch application
+
−
process often results in an extremely fast development cycle unincumbered by <b>low</b> performance [[Infrastructure_Problems#CVS|CVS server]].
+
  
−
=== compile fragility ===
+
Note that the mess is not too big. There might appear only few extra changes close before the ''"Released ooo-build"'' entry. For example, a tag might include the changes ''ABCDEFGH''. The branch might include ''ABXYCDEFGH'' ,where ''A'' is the release commit, ''B'' is hotfix of a potential build breakage, ''CDEFGH'' are normal changes committed by anyone to the remote repository before the deadline, ''XY'' are changes committed into the remote repository after the deadline but before the end of the release process.
  
−
To use up-stream OO.o it is not possible to use HEAD, due to multiple concurrent (slow) incomplete merges constantly in progress, instead one must use a milestone release. Unfortunately milestone releases build on a small number of tested setups - but these typically do not include out-of-the-box, stock Linux distributions
+
== Branching ==
−
such as OpenSUSE, Fedora, Debian etc. Thus from day-1 it is necessary to patch a milestone to get it to build
+
−
at all. Issues such as different gcc versions, different platform libraries etc. tend to cause this.
+
−
However - there is no central place where such patches can be collected to avoid constant duplication of effort,
+
−
apart from ooo-build.
+
  
−
It is hoped a [[Tinderbox Setup | tinderbox]] server with many disparate slaves building the CWS in the 'Ready for QA' state might
+
''Please see  the [http://freedesktop.org/wiki/Software/ooo-build/GettingIt#createbranch freedesktop.org wiki] for the authoritative info.''
−
help fix this problem in future.
+
  
−
=== interlocking changes ===
+
When there's a particularly good reason for a branch, such as a MWS is moved to the maintenance mode and we want open master for further development, one of the core ooo-build hackers will follow something like this process:
  
−
While a cws is waiting to be integrated / going through QA - it is entirely possible that another feature
+
* create the branch and anchor:
−
requires the functionality it provides; furthermore there is no easy way to include multiple features that we
+
** '''git checkout -b ooo-build-X-Y-Z master''' - do the branch for OOo-X.Y.Z from master
−
judge to be ready, yet would not pass up-stream QA (on multiple platforms etc.) into our builds. Thus ooo-build
+
** '''git tag -s OOO-BUILD-X-Y-Z-ANCHOR''' - this tags the current state so we can diff against it and see the branch specific changes
−
becomes a place to test multiple new features concurrently. It is hoped that the new <i>experimental</i> CWS
+
** modify the message printed at the end of ''configure.in''. It might be something like:
−
regimen may help fix this problem & accelerate up-streaming of patches.
+
**:<tt>This is ooo-build-2-0-4 - the stable branch for the 2.0.4 release.<br>If you want to build something cool, unstable, and risky, use master.</tt>
 +
** '''git commit -a''' - commit the changes, please make sure you mention the branch creation in the commit log
 +
** '''git push origin ooo-build-X-Y-Z:ooo-build-X-Y-Z''' - push the branch
 +
** '''git push --tags''' - push the tag
  
−
=== non-responsiveness / lack of leadership ===
+
* make changes specific for the original tree (master):
 +
** '''git checkout master''' - get sources from the original tree
 +
** if it is an important branch, such as for a minor OOo version, add a line to the message printed at the end of ''configure.in''. It might be something like:
 +
**:<tt>ooo-build-X-Y-Z  branch for X.Y.Z</tt>
 +
** '''git commit -a''' - commit the changes, please make sure you mention the branch creation in the commit log
 +
** '''git push''' - push the changes
  
−
Many ooo-build patches are ready for up-streaming but there is no / little response from up-stream. Worse there is the perception that taking leadership and actually doing something about merging fixes would be firmly opposed. Finally - even when maintainers are active, responsive & friendly - there is no agreed mechanism for blanket
+
Sample commit log:
−
approving fixes - or sub-types of trivial fixes, which thus tend to fester in IssueZilla.
+
  
−
At the time of writing ooo-build's patches are available here: http://go-oo.org/ooo-build/patches/src680/apply.
+
<pre>
 +
Branched for X.Y.Z.
  
−
FIXME - add some humerous details here / bug links etc.
+
OOO-BUILD-X-Y-Z-ANCHOR - the anchor tag,
 +
ooo-build-2-0-4 - the branch.
 +
</pre>
  
−
=== symbol font ===
+
== Support for new MWS ==
  
−
ooo-build contains a substantially improved OpenSymbol font: opens___.ttf improved mostly but cut/pasting existing glyphs to new positions to match the mapping table in vcl. This results in a massively improved PPT/Word bullet experience with little effort. It is not acceptable up-stream for reasons unexplained.
+
When the upstream branches new MWS and we want to support it in ooo-build, one of the core ooo-build hackers will follow something like this process:
  
−
=== font substitution ===
+
* first, it is better to clean ooo-build and remove support for all old and obsolete milestones; FIXME: it will be described somewhere else
 +
*'''git pull -r''' - get the latest everything
 +
*edit ''download.in'', mention the new tarball file name and URL in the array ''%SRC_URLS'', something like:
 +
*:<tt>              'oox680-m.*'                        => '@MIRROR@/OOX680',</tt>
 +
*edit ''patches/src680/apply''
 +
**fix the ''OLDEST_SUPPORTED'' option; note that more MWSs can be supported, it might be something like:
 +
**:<tt>OLDEST_SUPPORTED=src680-m181,ooe680-m1</tt>
 +
**fix the conditions for the various sections; note that you must add condition for the new MWS everywhere where a condition for another MWS already exists; it might look like:
 +
**:<tt>[ Fixes >= src680-m182 >= ooe680-m2 ]</tt>
 +
*might want to use the new milestone by default, then update ''DEFAULT_TAG'' in ''configure'' in, it looks like:
 +
*:<tt>DEFAULT_TAG=oox680-mY</tt>
 +
*'''git commit -a''' - describe all changes in the commit message; it is usually enough to mention something like:
 +
*:<pre>
 +
*:Support for oox300.
 +
*: 
 +
*:* download.in, patches/src680/apply: Support for oox680
 +
*:* configure.in: Default to oox680-mY
 +
*:</pre>
 +
*'''git push'''
 +
*it's then customary to announce this kind of change
  
−
Many vendors ship AGFA's propriatory metric-compatible fonts with OO.o - it is thus necessary to run several seds on the VCL.xcu [ further bloating this already gigantic messy beast ]. We also remove some of the more foolish &amp; enthusiastic font-usage of eg. the metrically-extremely-strange bitstream font eg. <code>bin/font-munge.pl</code>
+
== Support for final OOo version ==
  
−
    s/(Bitstream Vera Sans;.*)Albany;/Albany;$1/;
+
When the upstream releases final version of a MWS, one of the core ooo-build hackers will follow something like this process:
−
    # add AMT fonts
+
−
    s/Albany;/Albany AMT;Albany;/g;
+
−
    s/albany;/albanyamt;albany;/g;
+
  
−
=== parallel build support ===
+
* must check whether the final sources differ from the latest milestone; if the sources are the same, only symlink is made at go-oo.org/packages; new sources are created otherwise; the new tarball name is something like ''OOO_X_Y_Z''
 +
* do all the steps as in case of [[ooo-build#Support for new MWS|support for new MWS]] with the following modifications:
 +
** use the tarball name ''OOO_X_Y_Z'' instead of the MWS- and milestone-based name ''oox680-mY''
 +
** if the sources are only symlinks to the lates milestone, hack ''bin/unpack'', so it creates the symlink to the unpacked sources; it might look like:
 +
**:<pre>
 +
**:if test -d oox680-mY -a ! -d OOO_X_Y_Z ; then
 +
**:    echo "Linking rcZ to X.Y.Z"
 +
**:    ln -sf oox680-mY OOO_X_Y_Z
 +
**:fi
 +
**:</pre>
  
−
There are a chunk of ice-cream / massively parallel fixes in ooo-build, it's not clear who owns reviewing / accepting these up-stream.
+
== Remaining unsolved issue summary ==
−
 
+
−
=== no 'UI' team ===
+
−
 
+
−
The up-stream UI team have come up with master-pieces of UI design such as the Yes/No dialog on
+
−
 
+
−
"Would you like to not continue saving in the original OpenOffice.org 2.0 format or perhaps switch to another format"
+
−
 
+
−
that takes 10 seconds to parse each time ( presumably since it's a recent feature - with a specification too ).
+
−
 
+
−
The rest of us mere-mortals know that the OO.o is <b>shockingly</b> broken - and hence are eager to fix it
+
−
without being blocked & frustrated for weeks by those responsible for the current mess.
+
−
 
+
−
A number of the changes / patches in apply/ are blocked on 'user experience' feedback.
+
−
 
+
−
=== different defaults ===
+
−
 
+
−
It is self evident to ooo-build users that a slew of dialogs on 1st run is a painful mess; eg. if there are settings to migrate, don't shout about it - do it silently. Furthermore - the registration dialog looks tacky,
+
−
we disable both. We also alter a number of other defaults. cf. the last point - I'm optimistic that these will
+
−
~never get up-stream agreement.
+
−
 
+
−
=== bleeding-edgeness ===
+
−
 
+
−
There is a 'cool factor' to building the very latest things yourself; and helping solve problems with them.
+
−
It's nice to be able to see your changes have an effect &amp; help others rapidly, eg. a fix being immediately
+
−
useful to other people. Of course - you can have too much of a good thing here but ...
+
−
 
+
−
=== Philosophical differences ===
+
−
 
+
−
==== compatibility ====
+
−
 
+
−
Up-stream believe that the most important data set to be compatible with is existing StarOffice / OO.o users.
+
−
ooo-build users believe that nearly all the world's data is stored in Microsoft Office format - hence we
+
−
sacrifice legacy support for better interop.
+
−
This is of course a continuum, up-stream are at the luney extreme of pushing back-compatibility regardless
+
−
of it's impact on interoperability, even in cases deliberately excluding useful interoperability improvements
+
−
on that basis. ooo-build appreciates backwards comaptibility, but is in favour of viewing core differences
+
−
that are non-interoperable as bugs not features.
+
−
 
+
−
==== process complexity ====
+
−
 
+
−
ooo-build users believe in programmer lead development, with strong peer review and user QA.
+
−
up-stream believe in process based development, with teams, consensus building, specification writing, test-instead-of-detailed-code-review, and all these 'Professional' pasttimes.
+
−
ooo-build users believe the OO.o we have today is broadly a product of these processes. Up-stream users
+
−
believe the previous sentence is a compliment.
+
−
 
+
−
==== cross-platform ====
+
−
 
+
−
ooo-build enables patch sub-setting, thus we include patches for features (eg. Mono integration) that are
+
−
most likely not well separated, and will break the Win32 build. Of course, for ooo-build these are not
+
−
enabled on Win32 thus causing no problem. This is an impediment to getting work up-stream. Hopefully
+
−
the 'experimental' process may help encourage good behavior here.
+
  
−
=== FIXME ===
 
  
−
Lots more to be said here ...
+
Information placed below here previously, was rather outdated. Pls. find up to date info on this page of the OpenOffice.org project: [[Community_Council/Project_Improvements | Project_Improvements]], or linked from there.
 +
Of course, what was here before, may be read in the history of this very page.
  
 
== Conclusion ==
 
== Conclusion ==
Line 233: Line 302:
 
If you read all that don't get depressed - these issues can all be fixed - many of them almost painlessly. We hope to shrink this page quickly.
 
If you read all that don't get depressed - these issues can all be fixed - many of them almost painlessly. We hope to shrink this page quickly.
  
−
[[Category: Development]]
+
[[Category:Build_System]]

Latest revision as of 20:13, 1 July 2018

This collection of patches, artwork and build infrastructure exists solely as a reflection of the many problems encouraging reasonably responsive change up-stream. The process of change is painful for any organisation, the larger the more painful. However - the size of the problem is no excuse to not try; hence the evenutal aim is to remove the need for ooo-build by incrementally fixing the various problems.

Documentation note.png This page has a long history. Information about more recent improvements (done / in progress) should be found at Community Council / Project Improvements.

About ooo-build

ooo-build arose from acute frustration with the bad-old days of OOo process before the Child Workspace concept was introduced, it was also fueled by a non-performant CVS server. Things have been further improved in the mean time, see the Build guide.

Checking out

To check out trunk ooo-build from the fd.o git repository, run one of the following in the command line: 

# anonymous access
git clone git://anongit.freedesktop.org/git/ooo-build/ooo-build
# if you have a freedesktop.org account
git clone ssh://[username@]git.freedesktop.org/git/ooo-build/ooo-build

If you need to work on a branch: 

git checkout -b ooo-build-3-0-1 origin/ooo-build-3-0-1

(see fd.o wiki for authoritative info)

Making a patch on a set of files

ooo-build itself is in git - but as a set of patches, not the patched OOo sources themselves. Working with patches is unfortunately not too straightforward and needs some training; but you can use git to make some of the operations easier by creating a local git tracking of the patched OOo sources, like: 

make patch.apply
cd build/oooABC-mXY
git init
../../bin/create-gitignores.sh
# if you want to track just the 'sc' project
git add sc
# or instead track everything
git add .
git commit -m "initial"

Now you can create a new patch like this: 

cd build/oooABC-mXY
# create a branch for the development
git checkout -b tempbranch
# modify the file, eg sc/blah/bleh.cxx
# and commit it
git add sc/blah/bleh.cxx
git commit
# edit something else, commit, etc.
# create the patch
git diff --no-prefix master tempbranch > ../../patches/dev300/blah.diff
# now switch back to master
git checkout master
# and add the patch to ../../patches/dev300/apply (as described below)

To update an existing patch, you'll probably want to do something like this: 

# create a temporary branch
cd build/oooABC-mXY
git checkout -b tempbranch
# unapply the patch
patch -p0 -R < ../../patches/dev300/blah.diff
# commit the revert
git commit -am revert
# apply the patch again to be able to edit it
patch -p0 < ../../patches/dev300/blah.diff
# edit it, commit the changes
# when you are happy, find the commit id of the 'revert' commit
git log
# generate the patch
git diff --no-prefix id-of-the-revert-commit > ../../patches/dev300/blah.diff
# switch back to master
git checkout master

To remove the git tracking : 

rm -rf .git

You can also think of more fancy use of git, like having a master branch for applying the patches, and other branches to track history of development you are doing, or use it to actually edit existing patches, to merge patches, etc.

Some people prefer stacked git (stg) over plain git when juggling with patches, after the initial "git init; git add .; git commit -a" do a "stg init" - and read the nice manual page.

Adding Patch

One of the main ooo-build features is the ability to apply patches against the upstream sources. A patch can be added the following way:

  • propose a patch file name:
    • the file suffix .diff is required
    • the file name <theme>-short-fix-description.diff is suggested when there are more thematic patches, e.g. warnigns, unittesting, speed that are not put in any thematic directory
    • the file name <module>-short-fix-description.diff is suggested when the patch modifies only one source module, e'g' vcl, svx, sd
    • the file name cws-<name> should be used for CWS backports
    • the file name short-fix-description.diff is enough otherwise
  • create the patch in the format to be applied in the top source directory with -P0, see the sample content: 
    

    --- jvmfwk/plugins/sunmajor/pluginlib/gnujre.cxx.old    2007-08-10 17:32:26.0000

    

    +++ jvmfwk/plugins/sunmajor/pluginlib/gnujre.cxx        2007-08-16 22:40:42.0000

    

    @@ -78,6 +78,7 @@ char const* const* GnuInfo::getJavaExePa 

    

    ...

    

    

    

    

    • 

  • put the patch below ooo-build/patches/<group>; most patches are located in the MWS specific directory. Some bigger groups of patches have their own thematic directory. For example:

    

    

    patches/src680/sc-save-split-view.diff

    

    patches/src680/warning-return-values-filter.diff

    

    

    

    patches/scsolver/scsolver-source-inc-basedlg-hxx.diff

    

    patches/scsolver/scsolver-source-inc-baselistener-hxx.diff

    

    

    

    

    • 

  •  mention the patch in the apply file:

      

    • ooo-build allows to sort the patches into groups and apply them conditionaly by distributions. Therefore, each patch has to be mentioned in the right section in the apply file. This file is usually located in the MWS-specific directory, e.g. patches/src680/apply.

      • 

    • the patch entry might look like:

      

       
      

       [ CalcFixes ]

      

      

      

       # Support Hungarian localized keywords for CELL and INFO functions.

      

       sc-celltrans-hungarian-keywords.diff, i#80299, kohei

      

       # Fix saving split-view information on 64-bit platforms.

      

       sc-save-split-view.diff, n#235131, i#81936, jonp

      

      

      • 

    • please do not forget to mention the issue numbers and the responsible developer name

      • 

    • note that the patches are applied in the order in which they are listed in the apply file. If there are some conflicts between the patches, it might be necessary to split a section, for example:

      

      

       [ Fixes ]

      

      

      

       # make unzip command not ask when overwriting files

      

       unzip-command.diff, i#81087, fridrich

      

      

      

       [ CalcFixes ]

      

      

      

       #fix import filter for userforms with calc specific data ( rowsource ) 

      

       svx-filter-userform-rowsource.diff, i#73753

      

      

      

      [ Fixes ]

      

      

      

       # edit fields text displaying

      

       svx-sdrobjeditview-update-edit-area.diff, n#305205, rodo

      

      

      • 

    

    • 



Committing a Change


Please see the freedesktop.org wiki for the authoritative info.

In git, the commits happen locally.  To make them available on the server, you have to either push them (if you have the freedesktop.org account), or mail them (if not).



# it is our first session, we have to clone the repository
git clone ssh://[username@]git.freedesktop.org/git/ooo-build/ooo-build
# develop something, now commit it
git commit -a
# continue developing, and commit it
git commit -a
# it is finished, patches apply, everything builds, let's check that we did not
# forget uncommitted changes
git status
# looks fine, let's double check the diff
git log -p
# everything is perfect, let's push to the remote repository
git push
# oh, it failed! - somebody committed some changes in the meantime, let's update
git pull -r
# double check
git log -p
# everything is fine
git push



The form of the commit message should be like the following:



First line roughly describing the change.

Leave one empty line, and then follow with more detailed description
what and why you changed.  This is really important, because some
of the git tools (like gitk, git log --pretty=oneline, git rebase
--interactive, etc.) show just the first line.  Also we don't have
a ChangeLog any more, so git log is now your source of the information
about the changes.

Please do not forget to mention the bugzilla numbers, like i#12345 or
bnc#234567.

* file1: Did this and that.
* file2: And something else here.



Releasing


When there's a particularly good reason for a release, such as a distro needs a stable base or we want to do something potentially
disruptive, one of the core ooo-build hackers will follow something like this process:



    

  •  git pull -r - get the latest everything

    • 



    

  •  do a test build and a smoke test to make sure that the last commits are fine; you could commit any fix if needed; you need not push it, though

    • 



    

  •  read back through the git log and update the NEWS file for the release, summarizing and attributing the changes. See also below for "Tag vs. Push"

    • 



    

  •  edit configure.in, bump the version in the AC_INIT line, incrementing the minor version eg. AC_INIT(ooo-build, X.Y.Z)

    • 



    

  •  git commit -a - commit the changes with a handy comment, so we can roughly see where this happened in the flow:

    • 



Released ooo-build-X.Y.Z  (X.Y.Z-betaM)

* version X.Y.Z (X.Y.Z-betaM)
* tag OOO_BUILD_X_Y_Z



    

  •  git tag -s OOO_BUILD_X_Y_Z - create a signed tag for the given release; it is IMPORTANT so that anyone could check out exactly these sources anytime later; note that we might need to push another version later, see below for "Tag vs. Push"

    • 



    

  •  ./autogen.sh - this re-builds configure with the version in place; a distro must be specified eg. ./autogen.sh --with-distro=GoOoLinux

    • 



    

  •  make dist - this builds the archive containing everything.

    • 



    

  •  md5sum ooo-build-X.Y.Z.tar.gz > ooo-build-X.Y.Z.tar.gz.md5 - so that users can do at least the basic consistency check

    • 



    

  •  scp ooo-build-X.Y.Z.tar.gz* ooweb@seagull.dreamhost.com:~/download.go-oo.org/<MWS_DIR>/ - uploads the tarball and the .md5 file for the right Master Work Space, eg. OOO310

    • 



    

  •  It's then customary to announce the release, see the template in doc/announce.txt - update all the ***s to the right versions, insert the contents of NEWS, fire and forget.

    • 



    

  •  git pull -r - get the last changes from the remote repository to be able to push the changes; this might cause reordering of the git log, see below  "Tag vs. Push"

    • 



    

  •  git push --tags - push the changes, including the tag,  to the remote repository

    • 



Tag vs. Push


IMPORTANT:  You should always check out the tag or check the released tarball to make sure what changes are included.

We do the tag in the local git copy. We need to do git pull -r before git push --tags. It means that the recent changes in the remote repository will be moved before the last local changes. It means that there might be added some entries in the "git log" before the "Released ooo-build-X.Y.Z" entry. It means that the global "git log" does not mention correctly what changes are included in what release.

Note that the mess is not too big. There might appear only few extra changes close before the "Released ooo-build" entry. For example, a tag might include the changes ABCDEFGH. The branch might include ABXYCDEFGH ,where A is the release commit, B is hotfix of a potential build breakage, CDEFGH are normal changes committed by anyone to the remote repository before the deadline, XY are changes committed into the remote repository after the deadline but before the end of the release process.



Branching


Please see  the freedesktop.org wiki for the authoritative info.

When there's a particularly good reason for a branch, such as a MWS is moved to the maintenance mode and we want open master for further development, one of the core ooo-build hackers will follow something like this process:



    

  •  create the branch and anchor:

      

    •  git checkout -b ooo-build-X-Y-Z master - do the branch for OOo-X.Y.Z from master

      • 

    •  git tag -s OOO-BUILD-X-Y-Z-ANCHOR - this tags the current state so we can diff against it and see the branch specific changes

      • 

    •  modify the message printed at the end of configure.in. It might be something like:

      

      This is ooo-build-2-0-4 - the stable branch for the 2.0.4 release.
      If you want to build something cool, unstable, and risky, use master.      

      

      

      • 

    •  git commit -a - commit the changes, please make sure you mention the branch creation in the commit log

      • 

    •  git push origin ooo-build-X-Y-Z:ooo-build-X-Y-Z - push the branch

      • 

    •  git push --tags - push the tag

      • 

    

    • 



    

  •  make changes specific for the original tree (master):

      

    •  git checkout master - get sources from the original tree

      • 

    •  if it is an important branch, such as for a minor OOo version, add a line to the message printed at the end of configure.in. It might be something like: 

      

      ooo-build-X-Y-Z  branch for X.Y.Z

      

      

      • 

    •  git commit -a - commit the changes, please make sure you mention the branch creation in the commit log

      • 

    •  git push - push the changes

      • 

    

    • 



Sample commit log:



Branched for X.Y.Z.

OOO-BUILD-X-Y-Z-ANCHOR - the anchor tag,
ooo-build-2-0-4 - the branch.



Support for new MWS


When the upstream branches new MWS and we want to support it in ooo-build, one of the core ooo-build hackers will follow something like this process:



    

  •  first, it is better to clean ooo-build and remove support for all old and obsolete milestones; FIXME: it will be described somewhere else

    • 

  • git pull -r - get the latest everything

    • 

  • edit download.in, mention the new tarball file name and URL in the array %SRC_URLS, something like:

    

                   'oox680-m.*'                         => '@MIRROR@/OOX680',

    

    

    • 

  • edit patches/src680/apply

      

    • fix the OLDEST_SUPPORTED option; note that more MWSs can be supported, it might be something like:

      

      OLDEST_SUPPORTED=src680-m181,ooe680-m1

      

      

      • 

    • fix the conditions for the various sections; note that you must add condition for the new MWS everywhere where a condition for another MWS already exists; it might look like:

      

      [ Fixes >= src680-m182 >= ooe680-m2 ]

      

      

      • 

    

    • 

  • might want to use the new milestone by default, then update DEFAULT_TAG in configure in, it looks like:

    

    DEFAULT_TAG=oox680-mY

    

    

    • 

  • git commit -a - describe all changes in the commit message; it is usually enough to mention something like:

    

    

    Support for oox300.

    

      

      

    •  download.in, patches/src680/apply: Support for oox680

      • 

    •  configure.in: Default to oox680-mY

      • 

    

    

    

    

    

    • 

  • git push

    • 

  • it's then customary to announce this kind of change

    • 



Support for final OOo version


When the upstream releases final version of a MWS, one of the core ooo-build hackers will follow something like this process:



    

  •  must check whether the final sources differ from the latest milestone; if the sources are the same, only symlink is made at go-oo.org/packages; new sources are created otherwise; the new tarball name is something like OOO_X_Y_Z

    • 

  •  do all the steps as in case of support for new MWS with the following modifications:

      

    •  use the tarball name OOO_X_Y_Z instead of the MWS- and milestone-based name oox680-mY

      • 

    •  if the sources are only symlinks to the lates milestone, hack bin/unpack, so it creates the symlink to the unpacked sources; it might look like:

      

      

      if test -d oox680-mY -a ! -d OOO_X_Y_Z ; then

      

          echo "Linking rcZ to X.Y.Z"

      

          ln -sf oox680-mY OOO_X_Y_Z

      

      fi

      

      

      

      

      • 

    

    • 



Remaining unsolved issue summary


Information placed below here previously, was rather outdated. Pls. find up to date info on this page of the OpenOffice.org project:  Project_Improvements, or linked from there. 
Of course, what was here before, may be read in the history of this very page.



Conclusion


If you read all that don't get depressed - these issues can all be fixed - many of them almost painlessly. We hope to shrink this page quickly.







Retrieved from "https://wiki.openoffice.org/w/index.php?title=Ooo-build&oldid=239772"

				
				

	





	
	

		
Personal tools