Difference between revisions of "User:ErAck/WorkFlow"

From Apache OpenOffice Wiki
Jump to: navigation, search
(ccache)
(build)
Line 11: Line 11:
  
 
With the migration to [[OOo_and_Subversion| SVN]] the .svn/* subdirectories'
 
With the migration to [[OOo_and_Subversion| SVN]] the .svn/* subdirectories'
content comes in the way when using <code>grep -r ...</code>, so at home in
+
content comes in the way when using ''grep -r ...'', so in ''~/.bashrc''
<tt>~/.bashrc</tt> I have
+
I have
 
  export GREP_OPTIONS='--exclude=\*.svn\*'
 
  export GREP_OPTIONS='--exclude=\*.svn\*'
respectively at work in <tt>~/.cshrc</tt>
+
respectively in ''~/.cshrc''
 
  setenv GREP_OPTIONS '--exclude=\*.svn\*'
 
  setenv GREP_OPTIONS '--exclude=\*.svn\*'
  
Line 39: Line 39:
 
for example <tt>cwsname/DEV300/src.m42</tt>
 
for example <tt>cwsname/DEV300/src.m42</tt>
  
=== Configure ===
+
 
 +
=== configure ===
  
 
When I don't need a full-blown tree because I don't plan to work on globally
 
When I don't need a full-blown tree because I don't plan to work on globally
used stuff that would also affect the much disregarded <tt>binfilter</tt>
+
used stuff that would also affect the much disregarded ''binfilter'' binary
binary filter module, I of course exclude that from the build, and I exclude
+
filter module, I of course exclude that from the build, and I exclude many
many others as well. This boils build time down to 2 hours for the entire tree
+
others as well. This boils build time down to 2 hours for the entire tree
 
[hey, you Windows guys are getting envious, aren't you? ;-)]. My configure
 
[hey, you Windows guys are getting envious, aren't you? ;-)]. My configure
 
call currently (2009-02-01) is
 
call currently (2009-02-01) is
Line 52: Line 53:
  
 
Especially note
 
Especially note
; --enable-dbgutil : This builds a non-product version with assertions and various checks during runtime enabled. The output directories are without the <tt>.pro</tt> extension, for example <tt>unxlngi6</tt> instead of <tt>unxlngi6.pro</tt>
+
; --enable-dbgutil : This builds a non-product version with assertions and various checks during runtime enabled. The output directories are without the ''.pro'' extension, for example ''unxlngi6'' instead of ''unxlngi6.pro''
 
; --disable-strip-solver : Symbols are not stripped from the libraries, so we'll have useful information in the debugger for backtraces.
 
; --disable-strip-solver : Symbols are not stripped from the libraries, so we'll have useful information in the debugger for backtraces.
 +
  
 
=== More shell variables ===
 
=== More shell variables ===
Line 74: Line 76:
 
export BUILD_COMMAND="perl $SRC_ROOT/solenv/bin/build.pl"
 
export BUILD_COMMAND="perl $SRC_ROOT/solenv/bin/build.pl"
 
</source>
 
</source>
 
  
 
; TMP : For some reason (is there any?) configure does not inherit that, so set again.
 
; TMP : For some reason (is there any?) configure does not inherit that, so set again.
 
; CCACHE_DIR and ccache : Speeds up things significantly when rebuilding source. Note that the cache directory is setup such that different milestones and product and non-product versions don't interfere.
 
; CCACHE_DIR and ccache : Speeds up things significantly when rebuilding source. Note that the cache directory is setup such that different milestones and product and non-product versions don't interfere.
; LOCALINSTALLDIR and PKGFORMAT : Building the installation set in module <tt>instsetoo_native</tt> creates a directly usable installation instead of packages. The location is, for example, .../cwsname/DEV300/inst.m42/...
+
; LOCALINSTALLDIR and PKGFORMAT : Building the installation set in module ''instsetoo_native'' creates a directly usable installation instead of packages. The location is, for example, .../cwsname/DEV300/inst.m42/...
 
; BUILD_COMMAND : ''build'' actually is an alias, setting up a variable enables use in inherited shells, from within the editor, or simply in a <code>time $BUILD_COMMAND --all</code> invocation.
 
; BUILD_COMMAND : ''build'' actually is an alias, setting up a variable enables use in inherited shells, from within the editor, or simply in a <code>time $BUILD_COMMAND --all</code> invocation.
 +
  
 
==== ccache ====
 
==== ccache ====
Line 92: Line 94:
 
export CXX="ccache g++"
 
export CXX="ccache g++"
 
</source>
 
</source>
 +
 +
 +
=== build ===
 +
 +
In the OOo tree's root, effectively being <tt>.../cwsname/DEV300/src.m42</tt>
 +
in this example, execute
 +
 +
<source lang="bash">
 +
source LinuxX86Env.Set.sh
 +
./bootstrap
 +
cd instsetoo_native
 +
build --all -- -P2
 +
</source>
 +
 +
Note that I don't invoke the ''dmake'' command in the tree's root.
 +
Reasons are:
 +
 +
* Fine grained call of the ''build'' command, specifying the number of processes to use. Here I create 2 dmake processes per source directory entered by the build script. As a rule of thumb, use 2 processes per CPU core, so if one is waiting for disk IO the other can do useful things. Yes, this is a much simplified view.. For a CPU having 2 cores, this would make 4 processes. However, instead of simply specifying -P4 for dmake I prefer 2 build processes and 2 dmake processes per build process, which would be
 +
** <code>build -P2 --all -- -P2</code>
 +
* In case the build breaks, for example in module ''svx'', after having fixed things the build can be easily continued in that module by retrieving and editing the command line, while still in module ''instsetoo_native'':
 +
** <code>build --all:svx -- -P2</code>
 +
 +
Ah, and of course I use <code>time $BUILD_COMMAND --all -- -P2</code> instead
 +
and hope the build doesn't break so I can see 1:55:03 or some such ;-)

Revision as of 21:58, 1 February 2009

Here I'm noting down my work flow and environment I use when working on code, hopefully giving some useful hints for others.

System

Preferably Debian. Etch does it. Which is what I use at home. At work I use Kubuntu, Solaris/SPARC, Solaris/x86, MacOSX/x86, and with a ten-foot pole only when necessary Windows XP.

Shell environment

With the migration to SVN the .svn/* subdirectories' content comes in the way when using grep -r ..., so in ~/.bashrc I have

export GREP_OPTIONS='--exclude=\*.svn\*'

respectively in ~/.cshrc

setenv GREP_OPTIONS '--exclude=\*.svn\*'

Note: On some systems there's an old version of grep that doesn't know that option and bails out if set. This will break the build later, so check by setting the variable and invoke grep to see whether it complains, and if so do not set the variable.

Vim editor

I'm a Vim addict since the mid 90s, so I use the stuff lined out in Editor Vim.

Tools and Little Helpers

To tame the source base I heavily use exuberant ctags and GNU id-utils and sometimes cscope. For scripts generating databases suitable for OOo see the Little Helpers.

Building

Out of habits introduced at Sun Hamburg labs, I usually follow the same naming scheme also at home when setting up CWSs, which is to checkout source code into a subdirectory of $CWS_WORK_STAMP/$WORK_STAMP/src.milestone, for example cwsname/DEV300/src.m42


configure

When I don't need a full-blown tree because I don't plan to work on globally used stuff that would also affect the much disregarded binfilter binary filter module, I of course exclude that from the build, and I exclude many others as well. This boils build time down to 2 hours for the entire tree [hey, you Windows guys are getting envious, aren't you? ;-)]. My configure call currently (2009-02-01) is

./configure --disable-binfilter --without-fonts --without-ppds --disable-build-mozilla --with-system-stdlibs --enable-dbgutil --disable-strip-solver --disable-systray --with-build-version="Built by erAck" --with-vendor="erAck" --disable-odk --disable-qadevooo --disable-pdfimport --disable-mediawiki --disable-reportdesign --disable-neon --with-system-zlib --with-system-openssl --with-system-jpeg


Especially note

--enable-dbgutil 
This builds a non-product version with assertions and various checks during runtime enabled. The output directories are without the .pro extension, for example unxlngi6 instead of unxlngi6.pro
--disable-strip-solver 
Symbols are not stripped from the libraries, so we'll have useful information in the debugger for backtraces.


More shell variables

I add these to the end of LinuxX86Env.Set.sh, replace cwsname and m42 and the content of my_OOO_TREE as appropriate. For tcsh replace export var="..." with setenv var "..." and add to LinuxX86Env.Set instead.

export CWS_WORK_STAMP="cwsname"
export my_UPDMINOR="m42"
export WORKSPACE_STAMP="$CWS_WORK_STAMP"
export my_OOO_TREE="$HOME/ooo/src/$WORKSPACE_STAMP/$WORK_STAMP"
export TMP="/tmp"
export CCACHE_DIR="$my_OOO_TREE/.ccache_${my_UPDMINOR}_${INPATH}"
ccache -M 2G -F 100000
export LOCALINSTALLDIR="$my_OOO_TREE/inst.${my_UPDMINOR}"
export PKGFORMAT="installed"
export BUILD_COMMAND="perl $SRC_ROOT/solenv/bin/build.pl"
TMP 
For some reason (is there any?) configure does not inherit that, so set again.
CCACHE_DIR and ccache 
Speeds up things significantly when rebuilding source. Note that the cache directory is setup such that different milestones and product and non-product versions don't interfere.
LOCALINSTALLDIR and PKGFORMAT 
Building the installation set in module instsetoo_native creates a directly usable installation instead of packages. The location is, for example, .../cwsname/DEV300/inst.m42/...
BUILD_COMMAND 
build actually is an alias, setting up a variable enables use in inherited shells, from within the editor, or simply in a time $BUILD_COMMAND --all invocation.


ccache

On my system I have setup a symbolic link /usr/local/bin/gcc -> /usr/bin/ccache so every source I build uses ccache, I never encountered problems with that. If you want to use ccache selectively for OOo, add the following variables:

export CC="ccache gcc"
export CXX="ccache g++"


build

In the OOo tree's root, effectively being .../cwsname/DEV300/src.m42 in this example, execute

source LinuxX86Env.Set.sh
./bootstrap
cd instsetoo_native
build --all -- -P2

Note that I don't invoke the dmake command in the tree's root. Reasons are:

  • Fine grained call of the build command, specifying the number of processes to use. Here I create 2 dmake processes per source directory entered by the build script. As a rule of thumb, use 2 processes per CPU core, so if one is waiting for disk IO the other can do useful things. Yes, this is a much simplified view.. For a CPU having 2 cores, this would make 4 processes. However, instead of simply specifying -P4 for dmake I prefer 2 build processes and 2 dmake processes per build process, which would be
    • build -P2 --all -- -P2
  • In case the build breaks, for example in module svx, after having fixed things the build can be easily continued in that module by retrieving and editing the command line, while still in module instsetoo_native:
    • build --all:svx -- -P2

Ah, and of course I use time $BUILD_COMMAND --all -- -P2 instead and hope the build doesn't break so I can see 1:55:03 or some such ;-)

Personal tools