openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pedro Giffuni <>
Subject Re: GNU Environment (New Build on Solaris)
Date Mon, 07 Jan 2013 18:34:50 GMT

----- Messaggio originale -----
> Da: Jean-Louis 'Hans' Fuchs 

> 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.

Detecting gpatch first than patch would be interesting for FreeBSD too,
however, please don't play too much with (it's already ugly
in there).

We have some configure options for that:

We have been able to get rid fo gnucp in FreeBSD too, no idea if that is enough
for Solaris.

> 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

n general avoiding the use of GNU tools with more generic utilities is ideal.
In FreeBSD we were able to get rid of GNU coreutils (gcp and GNU mktemp
I think). BSD tar and BSD sed (included in illumos) work fine for us.
> * 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
Please note that this shebang would be totally unacceptable for AOO.

If you *have* to use bash try #/usr/bin/env bash

> 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)

Not a problem. A matter of documentation, I guess.

> 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

In general there is a lot of flexibility. It is ideal to use configure properly
to avoid doing work manually but as long as you don't interfere negatively
with other platforms it is OK.

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

That will be the interesting part.


View raw message