This is a heads-up about a change in the way we build the product that
is about to be pushed.
Current Situation
=============
Right know there are 2 main way to build the product. Both of them
rely on pulling the 'build' repo and using ./download in that repo to
pull the 19 others git repos.
The first method, the 'build-repo build' or 'distro-build' method
consist of doing ./autogen.sh --with-distro && ./download && make in
the 'build' git repo.
This method involve a rsync step that copy the content of a directory
called 'rawbuild' that contain - among other thing, a bunch of link
pointing back to the git repos contained in ./clone/*
This method also allow for the application of selected patch contained
in ./patches and the use of --with-distro autogen parameter that
simplify the definition of a bunch of ./configure parameters,
specifics to different distributions.
The rsync step in this method make it not developer friendly, since
any manual changes in the git repos require to re-trigger the rsync,
or some manual and error-prone patching trickery to build one's
changes.
The second method, the so-called 'rawbuild build' consist in cd-ing
into the rawbuild directory, and running the autogen.sh that is there,
and then 'make' there.
This method does not involve any patching, and unless you specify all
the autogen.sh parameters manually, build only the somewhat equivalent
of --with-distro=[Linux/MacOS/Window]LibreOffice
On the other hand, this method build directly from the git repos and
therefore any change in the source is picked-up right away. this make
hacking much easier and partial build much less problematic.
Yet the second method still is coupled with the 'build-repo'. That is
you still need to pull the 'build' git-repo to prime the setup.
Goal
====
The core goal of the upcoming changes is to allow for a slightly
modified 'rawbuild build' so that pulling of the 'build' git repo is
not necessary, while maintaining the ability, for now, to build using
the 'distro-build' method if one choose to. I will refer to this
modified rawbuild as a 'bootstrap-build' for reasons that will soon be
clear.
Bootstrap build
===========
After the changes are pushed in, the preferred way for hacker and
developers to build the product will be the one documented here:
http://wiki.documentfoundation.org/Development/Native_Build
(the note at the top will be removed when the changes are pushed)
The short version is:
git clone git://anongit.freedesktop.org/libreoffice/bootstrap libo
cd libo
./autogen.sh # add your favorite autogen parameters, just like in the
rawbuild method
make
Note that make take care automatically of doing ./download for you,
but you still will have to run ./g pull -r (no, not ./bin/g :-) ) to
pull new changes after the initial clone.
Impact on the 'distro-build'
====================
These changes impact the distro-build, but only with regards to the
directory structure of the intermediary layout used to rsync.
namely:
in the 'build' git-repository:
* the 'rawbuild' directory disappear
* a 'bootstrap' directory appear. it is what used to be ./clone/bootstrap.
* all the others ./clone/* are now in ./bootsrap/clone/*
* rsync is done using ./bootstrap as a base instead of rawbuild
for all intents and purpose this should not change anything in the
commands you type to build.
So if you start fresh, the instruction to do a 'distro-build' remain unchanged.
******** Attention *******
If you have an existing setup, _when_ the changes are pushed to master
and you pull them for the first time, you _HAVE_ to re-do your
autogen.sh and ./download step.
These have been modified to detect the situation where you still have
the old directory setup and convert it automatically during the
./download step.
Failure to do so will use outdated version of ./configure ./download
and other support scripts, which is guarantee to end poorly.
********
Be aware that there is no automated way to revert back to the old
setup: this is especially a concern if you try to check-out a tag or a
branch to a point _before_ these changes are merge.
A tag will be placed just before the merge of these changes, named
'LIBREOFFICE_PRE_BOOTSTRAP_BUILD' to allow, if needed, to setup a
fresh pull at a point before these change.
It is still possible to do a 'rawbuild' with this new setup, except
that instead of cd-ing to rawbuild you cd to bootstrap, and follow the
method described in the 'bootstrap build' section above. (except the
pull which is obviously already done).
Review
======
The planned changes are stagged in a branch called
feature/bootstrap-build. The changes are confined in the 'build' repo
and in the 'bootstrap' repo.
You can test either the distro-build method or the bootstrap method:
To test the bootstrap method: just follow the instructions described
in the 'Bootstrap build' section above, add a 'git branch -b
feature/bootstrap-build origin/feature/bootstrap-build' just after the
pull
To test the 'distro-build' (you should NOT do that with an existing
repo setup that you care about)
* pull the build-repo, autogen and ./download
* checkout the feature/bootstrap-build. run autogen (--with git) and download
* checkout the feature/bootstrp-build branch in the ./clone/bootstrap repo
* re-run autogen and download
* make
When
====
Unless I'm being instructed otherwise, these change are planed to be
pushed Tuesday 30th during the (European) late-night.
A mail to this list will be send immediately prior to the push.
Norbert
Context
- [Libreoffice] Attention: New build structure is coming! · Norbert Thiebaud
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.