Merging OO638C_MacOSX into OOO_STABLE_1
Edward Peterlin
06-15-02
Introduction
This Saturday I spent some quality time working on the migration between OO638C_MacOSX and the Darwin (X11) build of OOO_STABLE_1. This was the general series of steps I followed during this time, with and without support from my case of PBR.
Process
I based my process off of having the full set of patches from the OO638C to OO638C_MacOSX branches. Ostensibly, this should indicate what changes are necessary to get a successful compile for X11 or Quartz. I stored these in the directory /full_ooo_patches and you can reproduce this with whatever path you want by untarring the contents of my full patch tarfile into that directory.
So, as I progressed forward during the day, here's what I did. To set up the build environment, it's already assumed that you've performed and X11 configure invocation similar to other OS X build insructions on your patched source tree. Open a Terminal and execute the following:
- cd /openoffice-1.0
- source MacosxEnv.Set
Now perform the following:
- dmake
- look for the last known module that's building at the time, say PREMODULE
- after the module PREMODULE fails, or successfully builds, look for the next module whose build status can't be verified from either reports on the mailing list or from the status page. dmake indicates the module name by a line of 7 or more consecutive equals signs. Let's call this unverified module MODULE. We'll assume that MODULE built succssfully in OO638C_MacOSX, the majority of remaining modules. If it hasn't, then you should basically assume a non-empty patch file and just try to get it to build as best you can.
- more /full_ooo_patches/MODULE.OO638C.patch
- We now diverge unto two tracks:
- If the patch file is empty:
- cd /openoffice-1.0/MODULE
- build
- If the build is successful, update status page accordingly. If not, attempt to make changes necessary to get MODULE to compile successfully.
- deliver
- Were additional modifications to the sources required between 3 and 4? If so, then we generate a patch and file it in IssueZilla:
- cd /openoffice-1.0/MODULE
- cvs diff -u > ~/MODULE.OOO_STABLE_1.datestamp.patch
- File an IZ issue with the above file attached as a PATCH.
- Start the proces at the beginning , assuming that MODULE builds successfully and the following module is where we need to break next (essentially, MODULE becomes PREMODULE).
- If the patch file is not empty and contains patches other then changes to the RCS/CVS generated headers
- cd /openoffice-1.0/MODULE
- patch -p1 < /full_ooo_patches/MODULE.OO638C.patch
- Look at the output of the previous step for failed patches, stored in files ending in .rej.
- Examine each file ending in .rej individually to reapply any required source changes that couldn't be automatically merged. Changes only involving the RCS header (e.g. changes to author or version) can be ignored.
- cd /openoffice-1.0/MODULE
- build
- If the build isn't successful, go back to Step 4.
- After the module builds successfully: deliver
- Generate a patch for the module as follows:
- cd /openoffice-1.0/MODULE
- cvs diff -u > ~/MODULE.OOO_STABLE_1.datestamp.patch
- File an IZ issue with the above file attached as a PATCH.
- Start the proces at the beginning , assuming that MODULE builds successfully and the following module is where we need to break next (essentially, MODULE becomes PREMODULE).
- Every five times or so this process completes successfully, have a drink.
- If you've gotten this far, then MODULE will build for OOO_STABLE_1 without patches. You should inform the dev list and start the process over again using MODULE as the new PREMODULE. I did this step so many times that I decided to aggregate everything at the end of the day after I saw no traffic on the dev list.
Through the day I pretty much jsut assembly line performed the above and was able to get a number of modules succesfully porting. Note that breaking after each and every unknown module is important because some modules may contain patches in OO638C_MacOSX that fix runtime errors that will still allow them to build successfully in OOO_STABLE_1 without the patch being applied.