[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GNUstep Build Guide and other documents
From: |
Richard Stonehouse |
Subject: |
Re: GNUstep Build Guide and other documents |
Date: |
Mon, 6 Jan 2003 19:26:33 -0000 |
Having just built and installed GNUstep (stable) and GWorkspace 0.4.5
using the new Build Guide revision 1.5.0, I hope the following comments
(from the standpoint of a user, not a developer!) may be useful. Sorry
if they're a bit long and perhaps revealing of my ignorance.
Built under Red Hat 8.0, using gcc 3.2. The specified pre-requisites
were satisfied by already-installed software, except ffcall; but during
the GNUstep build, I had to instal the openssl-devel RPM to get the ssl
headers (which weren't in the already-installed openssl RPM).
It went remarkably smoothly; in marked contrast to setting up a previous
version of GNUstep and GWorkspace under Red Hat 7.2, back in the summer.
Congratulations! (Or should I be congratulating Red Hat on providing a
decent set of compilers and libraries at last?)
The Build Guide is a good document, easy to follow, and easy to download
and use offline (a major plus point for me, with a dial-up connection).
Checking the version numbers of installed software, I couldn't get some
of the more complex tests to work (the ones that do "strings `gcc
--print-file-name=...").
On an RPM-based system such as Red Hat, an alternative way of getting
version numbers is (e.g.):
$ rpm -qa --filesbypkg | grep libgmp.so
which yields
gmp /usr/lib/libgmp.so.3
gmp /usr/lib/libgmp.so.3.3.0
and then do
$ rpm -q gmp
yielding the result
gmp-4.1-4
Could perhaps be worth documenting this for the benefit of us users of
RPM-based distros? There are probably quite a lot of us and we will tend
to include the less technically clued-up. Better still if you could
state the RPM package names - but not sure whether they'll be the same
in all distros.
I got a bit confused working out what software versions to download from
where:
- the web-site pages tell a slightly different
story from the build guide; they ought to be
brought into line.
- it will be very hard to keep the build guide
up-to-date with changing versions of software;
suggest version numbers should be removed from
the build guide and reference made to a
summary table in the web pages.
- it got a bit confusing trying to correlate
information from different web pages; would
be better if all the version and download
information (pre-requisites, GNUstep core,
applications etc) were on a single page,
albeit a long one.
- I also got a bit confused between stable and
unstable versions, which are listed in the
same column of the tables; might be better to
have two columns side by side, one for the
stable and one for the unstable versions.
- I got lost looking for mirror sites and found
myself trawling through the GNU mirrors instead
of the GNUstep mirrors; there seems to be a
misleading reference somewhere.
Don't know if the above makes sense; if it would help, I could put
together a mock-up of the sort of thing I have in mind and put it up on
the web.
Some small problems re. boot scripts:
1. I wasn't quite sure what to do with the GNUstep.sh
script so I put it in /etc/profile.d, which seems
to work. Re-reading section 6 of the build guide,
maybe I should have written a script to call it and
put that into /etc/profile.d instead?
The only drawback I can see of the way I've done
it is that the gdomac and gdnc services don't get
started until the first application is called, but
I don't see this as a problem.
Possibly heretical aside - do these two services
do anything useful for me (on a non-networked
single-user workstation running only one GNUstep
application)? Gnome and KDE also seem to have this
habit of starting services - so, if you mix apps
from different "empires" in a promiscuous fashion,
you seem to collect an awful lot of services.
2. After completing the build of GWorkspace, I could
run it from the terminal in which I'd done the build
but not from the Window Maker desktop menu. Solved
by logging out and in again (to get the GNUstep.sh
script executed). Maybe this is obvious to experts
but it baffled me for a bit! Worth adding to the
guide?
Another point for RPM users; to get a record of what's been installed
where, rather than the method given in the "Tips while installing"
section, I like to use the checkinstall program. Unfortunately this
doesn't work for installing GWorkspace - it falls over at the point
where it's merging the plist. Don't know whether this is a problem with
the GWorkspace build or with the checkinstall program?
Anyway, the build guide is a very handy document for users. If there's
any way I can actually help (rather than just criticising!) please let
me know.
--
Richard Stonehouse
- Re: GNUstep Build Guide and other documents,
Richard Stonehouse <=