[Open Office] Re: apply.pl & 'download' up-streaming ...
Petr Mladek
pmladek at suse.cz
Wed Mar 15 12:45:52 EST 2006
On Wednesday 15 March 2006 14:36, Martin Hollmichel wrote:
> Hi Petr,
>
> some common comments first: we really need more people involved than
> here on the cc list are addressed, we should really use
> dev at tools.openoffice.org for these efforts.
I agree. I added also the ooo-build-related mailing list to CC :-)
> I'm fine with creating own webpages on the site and the wiki for this
> but I'm usually a bit reluctant to create new projects and/or mailing
> lists because it creates just administrative overhead without benefits.
> I think the tools project is an adequate starting point, and we can
> create new pages or if really needed, new mailing list quite fast.
I am fine with it. The tools project looks like the right place.
I am going to wait for some more feedback now ;-)
> Petr Mladek wrote:
> > Hi,
> >
> > first, I am sorry for the delay.
> >
> > Wow, this looks like an attempt to push the whole ooo-build framework
> > upstream :-) Is this what you meant?
>
> yes, this it the picture we have, take the best of both world together
> into the main repository.
>
> Martin
>
> > I wrote a small intro.txt, see the attachments. It tries to describe the
> > current function of ooo-build. It helped me to sort the thinks and I hope
> > it would be useful for you as well.
> >
> >
> >
> >
> > Let me summarize our objectives. Please, correct me if I am wrong :-)
> >
> > 1. In each case, we should clean up ooo-build and push most of the hacks
> > upstream.
> >
> > I would differ two areas:
> >
> > a) hacks from scripts - They should be put into the upstream tools, such
> > as config_office/configure, make_installer.pl. It seems that I am
> > responsible for this area :-)
> >
> > b) patches against the upstream sources - This is another task in fact.
> > Michael has already started a great initiative to improve the current
> > state...
> >
> > I think that we need not to discuss this objective at this point. Michael
> > already localized many parts of ooo-build that should go upstream. I'll
> > continue and will do my best to do it step by step...
> >
> >
> > 2. We should split the ooo-build framework (scripts, documentation) from
> > the things that are specific for the current ooo-build community
> > (configure options, patches, distro specific hacks)
> >
> > I think that the framework would be an OOo community project at
> > http://projects.openoffice.org. It would be similar to the QA test tool.
> > So, it should have its own pages, mailing list, cvs module, etc.
> >
> > I expect that the current ooo-build community would still want to share
> > the patches, configuration, new features that are in development phase,
> > etc. somewhere else.
> >
> > This objective is not so clear and we should disccuss it here.
> >
> >
> >
> >
> > Here are my ideas about splitting ooo-build framework:
> >
> > You should read the attached intro.txt if you are not familiar with
> > ooo-build :-)
> >
> > The basic idea is that the framework should be universal. It needs to be
> > maintained. Though, the normal developer/packager should not need to
> > modify it to get a custom build. The normal developer should just put
> > there his/her own addons (patches, files) and do the build by: configure,
> > (download), make, make install.
> >
> > IMHO, this requirement is quite important. It would discourage developers
> > to use the framework if they have to commit patches against it as well.
> > It would be too schizophrenic, too many cvs, ... :-)
> >
> > What the custom builds usually requires? I found these areas in the
> > current ooo-build:
> > - configure, download, unpack, install additional sources
> > - define configuration of the upstream sources
> > - apply additional patches
> > - do some hacks before the build is started
> > - do some post install hacks
> > - re-arrange filelists
> >
> > So, I think that the best approach would be to make the framework
> > modular.
> >
> > Most of the areas are already solved this way in ooo-build. For example,
> > package-ooo calls standalone scripts ooinstall, install-dictionaries,
> > generate-bash-completion. We only need to define how the
> > additional/external modules would be processed, ...
> >
> > The same modular approach would be usable also for build-ooo...
> >
> > Note that also download, unpack, ... can be easily modularized.
> >
> > The most annoying problem is the configure script. IMHO, if the framework
> > is a standalone module, it needs his own configure. It should set what
> > sources needs to be download, what patches should be applied, etc. I
> > would need to be modular as well, so the user can add checks for his own
> > features. The configure modules could be solvable by a smart autogen.sh
> > script. Well, it looks a bit hackish but...
> >
> >
> > In fact, I would imagine that this framework can replace the module
> > config_office one day. If we do it well and the framework is really
> > stable and extensible by external modules. Though, it would need quite a
> > lot of real word testing, fixing, so I would prefere to develop it
> > without the slow CWS-game :-)
> >
> > What do you thing?
> >
> >
> >
> >
> > ------------------------------------------------------------------------
> >
> > Introduction into ooo-build
> > ===========================
> >
> > ooo-build provides an "easy" way for building and developing custom
> > builds of OpenOffice.org. It allows cooperation and work sharing of more
> > vendors.
> >
> > ooo-build supports building OOo the standard way: configure, make, make
> > install. It is able to apply lots of additional patches, hacks and fixes
> > withing the build and installation process. One release of ooo-build can
> > support more versions of OOo sources and more vendors. All the patches,
> > hacks, etc. can be effectively reused and shared. Finally, the are some
> > more scripts that are useful for developing OOo.
> >
> >
> > Example build using ooo-build
> > -----------------------------
> >
> > # get ooo-build, for example a released one from
> > # http://go-ooo.org/packages/OOO680/
> >
> > tar -xzf ooo-build-<version>.tar.gz
> > cd ooo-build-<version>
> >
> > ./configure \
> > --with-distro=SUSE \
> > --with-vendor=Novell \
> > --prefix=/usr \
> > --with-installed-ooo-dirname=ooo-2.0
> > --enable-binfilter
> >
> > ./download # this is one non-standard helper command, we added it because
> > # there are many sources to be downloaded.
> > # First, the OOo sources are split into more tarballs.
> > # In addition, ooo-build is able to use some more extra
> > # sources to enable features that have not been accepted
> > # by the upstream yet
> >
> > make
> >
> > make install
> >
> >
> >
> >
> > Configuration
> > -------------
> >
> > ooo-build has it's own configure script that has the following functions:
> > - select vendor and distro for which the custom build is being done
> > - select the right version of OOo sources
> > - set some custom setting that is not supported by upstream, such as:
> > --prefix
> > --with-installed-ooo-dirname
> > --with-binsuffix
> > --with-icecream-max-jobs
> > - enable/disable some optional features that are not yet configurable
> > by upstream, for example:
> > --enable-access (access import pieces via mdbtools)
> > --with-openclipart (extra galleries from OpenClipArt)
> >
> > The configure script generates the following files from the *.in
> > templates: - download
> > - bin/setup
> > - distro-configs/*.conf
> > - scratch/place
> > - intltools*
> > - and lots Makefiles all over the ooo-build sources
> >
> > The tool download will be described later, see below.
> >
> > The file bin/setup is a simple shell script that sets and exports some
> > shell variables. Many other ooo-build tools source this script to read
> > the setting.
> >
> > The config files distro-configs/*.conf include config switches that are
> > passed to the OOo native configure script during the build phase.
> > distro-configs/Common.conf includes some common options, shared
> > by all distributions. distro-configs/<vendor>.conf includes vendor
> > specific options. There is one for each vendor.
> >
> > The script scratch/place helps to develop huge fixes for OOo via the copy
> > of source files rather than by patches.
> >
> > intltools are three scripts that help us to update translations of some
> > additional files. They are actually used only to update some desktop
> > files.
> >
> >
> >
> > Downloading of ooo-build sources
> > -------------------------------
> >
> > The released versions of ooo-build and almost all the additional sources
> > can be download from http://go-ooo.org/packages/. Note that ooo-build
> > currently uses its own repacked OOo sources that are split into more
> > tarballs: binfilter, core, lang, sdk_oo, and system.
> >
> > There is the script "download" that is able to download all the necessary
> > sources. It is generated by ooo-build/configure, see above.
> >
> > It currently downloads:
> > - the split OOo source tarballs
> > - two dll files for mono stuff
> > - extras
> > - mdbtools source tarball
> > - hacked xt sources for build wit gcj
> > - etc.
> >
> >
> >
> >
> > Unpacking, preparing sources
> > ----------------------------
> >
> > There are some preliminary actions that are done when "make" is called.
> >
> > 1. bin/unpack is called. It is a simple shell script that unpacks all
> > the necessary tarballs into ooo-build/build directory or even into the
> > unpacked OOo source tree
> >
> > 2. Thereafter "make" installs some extra artwork, like vendor specific
> > bitmaps for splash screen.
> >
> > 3. Then the script bin/build-tools is called. It is able to build a
> > special version of gcc. It was used in the past to test build with
> > gcc-3.4.
> >
> > 4. Then patches/apply.pl is called. It applies all the selected patches,
> > see below for more details
> >
> > 5. Finally, bin/transform is called. This shell script currently calls
> > two scripts that update the default lists of fonts:
> > * bin/font-munge
> > * bin/help-font-munge
> >
> > All these steps are reversible. It is very helpful, for example, for
> > creating and testing incremental patches.
> >
> >
> > Something more about patches
> > - - - - - - - - - - - - - - -
> >
> > We currently have more than 500 patches. They are sorted into various
> > directories below ooo-build/patch. Then there is a so-called apply file
> > in ooo-build/patches/src680/. This file sorts patches into some more
> > groups, for example:
> >
> > [ QuickStarter ]
> > # An improved built-in quick-starter applet / systray thing. i#57872
> > speed-quickstart.diff
> > # An improved built-in quick-starter applet / systray thing. i#57872
> > speed-quickstart-eggtray.diff
> >
> >
> > Some patches could depend on the OOo source version, for example:
> >
> > [ TemporaryHacks < src680-m153 ]
> > # LD_LIBRARY_PATH should not end with a ":" N#118188, #55733
> > ld-library-path.diff
> >
> >
> > The apply file also allows to define groups of groups, for example:
> >
> > LinuxCommon : Common, BuildBitsLinuxOnly, LinuxOnly, SystemBits,
> > CWSBackports, G QPro, Lwp, cairocanvas, VBAObjects, msaccess, \
> > Safe64bit, FPickers, Mono, AddressBooks, QuickStarter,
> > Shrink
> >
> >
> > Finally, it defines what groups should applied for which distro, for
> > example:
> >
> > SUSE : NovellBase, BerkeleyDB43
> >
> >
> > This approach helps us to share work with more distributions. The
> > version-dependant patches are necessary because we do not want to force
> > everyone to use the same OOo source snapshot at the same time. One
> > snapshot is always set (in configure) as the default one but...
> >
> >
> >
> > Building
> > --------
> >
> > The command "make" calls bin/build-ooo after the sources are unpacked,
> > patched, and hacked.
> >
> > The main tasks of the script build-ooo are:
> > - run the OOo internal configure, see below* for more details
> > - source the generated *set.sh
> > - bootstrap OOo build
> > - build the module transex3 and update translations from extra GSI
> > sources if any available
> > - finish build
> >
> > In addition, there are some other build hacks and fixes, for example:
> > - export LANG="C"; export LD_ASSUME_KERNEL=2.2.5 to avoid problems
> > with Java on some platforms
> > - set extra flags for dmake to allow parallel build with icecream
> >
> > * The options for the OOo internal configure are read from bin/setup. It
> > combines options that are passed to the ooo-build/configure, and
> > options defined in ooo-build/distro-configs/*.conf
> >
> >
> >
> >
> > Installation
> > ------------
> >
> > The command "make install" calls bin/package-ooo. This script has the
> > following tasks:
> >
> > - install OOo
> > - install extra wrappers into /usr/bin
> > - install man pages
> > - install vendor specific desktop files and icons
> > - install extra dictionaries
> > - install script for bash completion
> > - build openclipart galleries
> > - remove copies of the English help and rather create symlinks
> > - hacks file lists:
> > - rearrange subpackages
> > - add some RPM specific tags, such as %config, %dir
> > - remove RPM specific destdir
> >
> > Some of the tasks are vendor specific, so there are many tests, such as:
> > if test "z$VENDORNAME" != "zNovell" ; then
> > ...
> > fi
> >
> > Some of the functionality is put into standalone scripts, for example:
> > - bin/ooinstall
> > - bin/build-galleries
> > - bin/install-dictionaries
> >
> >
> >
> > Misc stuff
> > ----------
> >
> > Everything above was necessary to build and install the custom build of
> > OOo.
> >
> > In addition there are some scripts that are helpful for developers, such
> > as: - bin/tunnel, bin/cws-commit-patch, bin/cws-extract, which are very
> > helpful for upstreaming patches and working with OOo cvs/CWS.
> > - bin/oosmoketest, bin/ootestapi, bin/ootesttool, bin/test-ooo,
> > bin/test-ooo-analyze, which might be useful for testing the custom
> > build. These are quite new, so it is still a work in progress.
> >
> > The directory ooo-build/scratch is used for developing huge fixes or
> > features. It allows to keep the current state in cvs via files instead of
> > patches. It is better because these kind of changes are usually developed
> > a longer time by more developers, ...
> >
> > The directory ooo-build/stamp is used by makefile. It helps to define
> > dependency between the various makefile targets.
> >
> > Finally, there are directories for some extra sources:
> > - ooo-build/desktop
> > - ooo-build/doc
> > - ooo-build/fonts
> > - ooo-build/man
> > - ooo-build/src
--
Best Regards,
Petr Mladek
software developer
---------------------------------------------------------------------
SuSE CR, s.r.o. e-mail: pmladek at suse.cz
Drahobejlova 27 tel:+420 296 542 373
190 00 Praha 9 fax:+420 296 542 374
Czech Republic http://www.suse.cz/
More information about the Openoffice
mailing list