Hello;
----- 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 configure.in (it's already ugly in there). We have some configure options for that: --with-gnu-patch= --with-gnu-perf= 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. http://lwn.net/Articles/343924/ 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. Pedro.
