As you all might have seen over the last day or so, I have tried to
implement most of what is recommended below.
I have tried to get what we can for free - without changing the
buildbot. If you are interested, go check the results of nightly builds
67-72.
I have backed out anything that break the build. (except for the deb +
rpm part, which I will revert in a minute)
Here is my approach on the buildbots - as always, I'm interested in lots
of feedback.
1. Linux 64 buildbot - this is the first bb and I just want a stable
build that builds the 'default build' - really a minimal build, and
can be used to identify when someone has 'broken the build' with a
patch. also used for running RAT scans, and potentially other code
optimization and security scans.
2. Linux 32 buildbot - when this comes online, this should be the 'full
build' which would be more useful for testing, etc. This could also
include a subset of translations, etc.
3. Windows buildbot - this would also be the 'full build' with a look
toward finding windows build bug and testing windows
4. Mac buildbot - similar to Win - same focus
5. Solaris build bot - similar to Win - same focus
6. Testing buildbot - when we finall have all of those going, it may be
interesting to set up a bb for doing automated testing (this would
be of course - down the road a bit...)
long discussion to explain why I've implemented the configure options
below and then one by one reverted them. I'm focusing on keeping a
running Linux 64 build, with the other goodies coming later.
As mentioned in a previous email, I'm working with infra on bringing
these online. A little patience is in order, but hoping to have more
stuff, soon...
A.
On 1/3/2012 3:29 AM, Jürgen Schmidt wrote:
On 1/2/12 9:46 PM, Ariel Constenla-Haile wrote:
Hi there,
now the buildboot's builds are configured with the following switches:
--with-jdk-home=/usr/lib/jvm/java-6-sun
--with-system-python
--enable-verbose
--with-package-format=deb
--with-build-version=2012-01-02
IMO those switches have the following drawbacks:
* system python should not be used. A universal Linux build should have
internal python instead
* package format should also include RPM packages
* builds should include category B
* the build boot should also build the extensions (AFAIK only the
Presenter Console, the Presentation Minimizer and the Wiki Publisher
are buildable after the ip clearance)
So I'd propose to use the following switches:
./configure \
--with-build-version="$(date +"%Y-%m-%d %H:%M:%S (%a, %d %b %Y)") -
Rev. $(echo $(svn info) | sed -e 's/^.*Last Changed Rev: //g' -e 's/
.*//g')" \
--enable-verbose \
--enable-category-b \
--enable-minimizer \
--enable-presenter-console \
--enable-wiki-publisher \
--enable-opengl \
--enable-dbus \
--enable-gstreamer \
--with-package-format="installed rpm deb"
The first switch
--with-build-version="$(date +"%Y-%m-%d %H:%M:%S (%a, %d %b %Y)") -
Rev. $(echo $(svn info) | sed -e 's/^.*Last Changed Rev: //g' -e 's/
.*//g')"
will produce a string in the About Dialog like this:
2012-01-02 17:20:41 (Mon, 02 Jan 2012) - Rev. 1226336
Adding date-time and revision info to the dialog is IMO a good idea.
The following switches
--enable-category-b
--enable-opengl
--enable-dbus
--enable-gstreamer
provide the basic a Linux AOO user could expect (OpenGL transitions,
GStreamer AVMedia plugin, all category B features).
The following switches
--enable-minimizer \
--enable-presenter-console \
--enable-wiki-publisher \
enable the three extensions.
Finally, the buildboot should be update to use EPM 3.7 patched with
http://svn.apache.org/viewvc/incubator/ooo/trunk/main/epm/epm-3.7.patch?revision=1162288&view=co
to produce packages installable on Debian.
it makes indeed sense to build epm not every time but we don't have to
replace the system epm. Instead we can put a patched version somewhere
on the build bot and can use
--with-epm=<path_to_patched_epm>
(we should change the configure switch to --with-epm-path to be more
consistent)
The same is true for dmake, don't know how it is find today on the
build bot.
--with-dmake-path=<path_to_dmake>
Everything else makes a lot of sense to me and we should use this
configuration on the build bots for the binary builds.
Maybe we should have a second configuration without any switches and
running the RAT scans and produce our source releases which we have to
provide.
Juergen
-------------------------------------------------------------------------
Final note for those trying to build themselves:
on a default installation of Ubuntu 10.04.3 LTS (Lucid Lynx) live-cd
image [1] you will have to add the following pakages to build AOO with
the above mentioned switches:
sudo apt-get install \
rpm \
autoconf \
libarchive-zip-perl \
g++ \
libcups2-dev \
libpam-dev \
openjdk-6-jdk \
gperf \
libfreetype6-dev \
libgtk2.0-dev \
libxaw7-dev \
bison \
flex \
libgconf2-dev \
libgnomevfs2-dev \
libdbus-glib-1-dev \
libgstreamer-plugins-base0.10-dev \
mesa-common-dev \
libgl1-mesa-dev \
libglu1-mesa-dev \
ant \
junit4 \
libidl-dev
[1] http://mirror.switch.ch/ftp/mirror/ubuntu-cdimage/lucid/
Regards
