openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Louis 'Hans' Fuchs <jean-louis.fu...@adfinis-sygroup.ch>
Subject GNU Environment (New Build on Solaris)
Date Mon, 07 Jan 2013 17:24:57 GMT
Hello Everybody

Abstract
-----------

Solaris has differtent system-tools, all the GNU tools are prefixed g- 
(ie. gtar). Some tools and dependencies of the build-system have to be 
installed from OpenCSW on older solaris. In this mail I discuss how to 
integrate these tools in the build-system and a policy to integrate 
latest AOO changes (toward GNU) into solaris.

Both topics are too connected to make two mails, but feel free to anwer 
only on one topic.

Tools Integration
----------------------

I start a build on a new solaris version. This time I like to ONLY do 
mergable changes. The main problem lies in the tools. Many tools (grep, 
sed, tar…) are detected in configure. On solaris it will typically 
detect (ggrep, gset, gtar…), but most scripts just use the stanard 
names anyway.

I don't have a problem with scripts not using the detected tool. I 
think we should define GNU-Tools as standard. Otherwise the already 
complicated build system gets unnecessary error sources.

I think there are two approaches:

A. Detect all the tools needed in the build system and have every 
script use the detected tool.
B. On systems that have prefixes for the GNU tools a pre-step in the 
build process creates a GNU Environment. This is how my build system 
currently works and it should IMO be integrated into the AOO 
build-system-bootstrap.

B "Virtual" GNU Env

(All problems in computer science can be solved by another level of 
indirection)

1. If /path/to/build is the build directory, a directory 
/path/to/build/bin should be created
2. The directory should be added to PATH="/path/to/build/bin:$PATH"
3. Find the g-prefixed tools and symbol link them into bin without prefix

On a current build system:
oobuild@sunt1000sparc ~/slave/aoo-trunk-solaris-11-sparc/build/bin [8 
files, 7.5K]  (master)
$> ls -l
total 9
lrwxrwxrwx   1 oobuild  staff         18 Oct 10 12:34 find -> 
/opt/csw/bin/gfind
lrwxrwxrwx   1 oobuild  staff         18 Oct 10 12:34 grep -> 
/opt/csw/bin/ggrep
lrwxrwxrwx   1 oobuild  staff         19 Oct 10 12:34 patch -> 
/opt/csw/bin/gpatch
lrwxrwxrwx   1 oobuild  staff         17 Oct 10 12:34 perl -> 
/opt/csw/bin/perl *
-rwxr-xr-x   1 oobuild  staff        107 Oct 10 12:34 pkg-config *
lrwxrwxrwx   1 oobuild  staff         17 Oct 10 12:34 sed -> /opt/csw/bin/gsed
lrwxrwxrwx   1 oobuild  staff         17 Oct 10 12:34 tar -> /opt/csw/bin/gtar

* Special Cases:

1. On some old solaris I can't easily install all the perl-modules 
needed for the build-system. So I installed perl using the thrid-party 
package manager OpenCSW.
2. As you see, since I had OpenCSW anyway I used all the OpenCSW tools 
to be consistant, many tools would be in standard solaris too.
3. pkg-config:

$> cat pkg-config
#!/bin/bash

export PKG_CONFIG_PATH="/usr/lib/pkgconfig:/usr/share/pkgconfig"
/opt/csw/bin/pkg-config "$@"

pkg-configs command line interaface on solaris 10 was outdated. So I 
installed pkg-config in OpenCSW, __BUT__ used a PKG_CONFIG_PATH that it 
only finds system libraries, NOT libraries from /opt/csw. I also 
checked that our build only depends on system libraries (with the 
exception of libpoppler for the pdf plugin)

These fixes must be merged into the build-system, so AOO will build 
out-of-the-box. Although I see no way around OpenCSW. But what packages 
from OpenCSW are needed could be added to the build-instructions.

Policy
---------

I need to find out what direction we should go, in order to make a 
decent proposal.

Can we make OpenCSW manatory? (All our clients had no problem with 
that, and it seems pretty standard)
Can we make the "virtual" GNU Env (build/bin) as part of 
build-system-bootstrap?

Then some policy definition:

1. I think it is quite possible that we have to link against a library 
from OpenCSW in future. Will that be ok?*

* libpoppler is an example. On customer uses the pdf plugin that has 
libpoppler from OpenCSW linked.

2. I'd vote for the following policy:

- Use everything possible from Standard Solaris
- Use tools when needed from OpenCSW
- Use these OpenCSW tools through the "virtual" GNU env (no adding of 
/opt/csw/bin to path)
- Use libraries from OpenCSW only if there is NO other solution
   - Only add library in a per module fashion:

export POPPLER_CFLAGS="-I/opt/csw/include -I/opt/csw/include/poppler"
export POPPLER_LIBS="-L/opt/csw/lib -lpoppler"

   - Never generally add /opt/csw/lib

Finally, since I like to switch to GNU-Compiler-Toolchain on solaris 
too, building this GNU-Environment will accompany this transition well.

Best,
   Jean-Louis

-- 
Adfinis SyGroup AG
Jean-Louis 'Hans' Fuchs, Software Engineer

Keltenstrasse 98 | CH-3018 Bern
Tel.: +41 31 550 31 11



Mime
View raw message