openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From janI <j...@apache.org>
Subject Re: GNU Environment (New Build on Solaris)
Date Mon, 07 Jan 2013 17:58:43 GMT
On 7 January 2013 18:24, Jean-Louis 'Hans' Fuchs <
jean-louis.fuchs@adfinis-sygroup.ch> wrote:

> 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.
>
Your proposal also has the advantage that when we move on with gbuild and
other changes in the build structure, it is easy to adapt to solaris.

The libraries is somewhat a different matter. Today bootstrap secures we
have the external libraries needed, I would prefer to keep that, and not
start having too many extra things that need to be installed manually.  We
also have to check the license of such libraries, many libraries are free
to use for individuals but not for organisations, depending upon such a
library would be a problem in my view.

As a side remark, I worked prof. with solaris about 5 years ago, and at
that time there was a BIG performance penalty when using gcc/g++ in large
projects compared to the sun compiler. That might have changed, but I
recommend strongly to test it.

Rgds
jan I.

>
> Best,
>   Jean-Louis
>
> --
> Adfinis SyGroup AG
> Jean-Louis 'Hans' Fuchs, Software Engineer
>
> Keltenstrasse 98 | CH-3018 Bern
> Tel.: +41 31 550 31 11
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message