On Sun, 20 Jan 2002, Rebecca J. Walter wrote:
 > Please everyone test this how to and see if it is lacking anything. It
 > is intended to be a beginner tutorial for compiling gimp 1.2 from CVS.
 > http://carol.gimp.org/gimp/howtos/cvs/cvs.html

Some parts of the tutorial are Linux-centric or bash-centric and
should probably be changed to support more UNIX-like operating
systems.  Even if most developers will probably use Linux, we should
not exclude the others in this howto.  Otherwise it will be hard to
get contributions for other platforms.

Here are some examples:

: The second step is to see if you have CVS packages installed.
: Type whereis cvs. If a path to a bin directory (like /usr/bin/cvs) appears,
: you are ready to go. If not, you will need to follow your distributions
: instructions and install it.

The command 'whereis cvs' is not available everywhere, or does not
always give the expected results.  For example, on my Solaris machine,
typing "whereis cvs" prints "cvs:" and nothing else (which means that
the command /usr/ucb/whereis cannot find cvs).  On the other hand, if
I type "which cvs", then it shows me the full path.  It would be
better to replace this sentence by:
   Type "whereis cvs", "type -p cvs" or "which cvs" depending on your shell.

In the "Compiling" section, there is another example using "whereis
aclocal".  This should also be changed.

: * diff -pu
: p adds the name of the changed function to the generated diff. This is a
: matter of taste, as it helps mostly when reading diffs. u makes the patches
: in unified diff format, which is widely considered both the most readable
: and the most robust patch format, however it doesn't work with old versions
: of cvs on HPUX and other old UNIX machines, diff -c should be used instead.

If I am not mistaken, the diff option in cvs passes the parameters to
the command-line diff program.  The "-p" option is an extension of GNU
diffutils that is not available in the standard diff found on many
UNIX systems.  So this is not only a problem for HP-UX or any "old"
systems, but also for the latest versions of Solaris, IRIX, AIX and
others.  I would change the last part of this paragraph as follows:
   [...], however the options "-p" and "-u" are non-standard extensions
   of the diff command that are not supported by all versions of diff,
   especially on systems other than Linux.  If your system does not
   understand "-u", you should use "diff -c" instead.

: Updating
: Later, when you want to refresh your versions, go into the cvs directory
: and type cvs up. To refresh just one module, go into the subdirectory for
: that module and enter cvs up. As simple as that.

Although "cvs up" is easier to type, "cvs update" is probably easier to
remember for first-time users.  It would be better to mention the full
name of the command at least once.  For example:
   [...] and type "cvs update" (or the shorter version "cvs up")

In the "Compiling" section, there are several examples showing how to
set environment variables with 'export "VAR=value"', followed by:

: If you use another shell, you will have to find out the appropriate
: syntax (or switch to bash).

Those who use (and prefer) a different shell will probably think that
this sentence is a bit arrogant.  It would be much better to give some
examples of the syntax supported by the other shells.  As far as I
know, all Bourne-based shells such as sh, bash, zsh and ash use the
"export" syntax (but some of them require two commands, one for the
"=" and one for "export") so the only other syntax that needs to be
explained is the "setenv" syntax used by all csh-based shells such as

The explanations can be repeated using "setenv", or the last sentence
could be replaced by something like the following:
   If you use another shell, you may have to use a different syntax
   than 'export VAR="value"'.  For csh and tcsh, you should use the
   syntax 'setenv VAR "value"' (note: there is no "=" sign between the
   variable and its value).

The second step ("2. Not it is time to compile. [...]") suggest to run
"./autogen.sh" without using any options.  It would be good to explain
at least the usage of the "--prefix" option.  The 4th step mentions
that the GIMP will be installed in /usr/local, but the user has not
been told about that until then.  It would be better to add some
comments earlier, saying that:
- "autogen.sh" will pass its arguments to "configure"
- the "--prefix" option can be used to install the GIMP in a different
   directory than the default /usr/local/.  This makes it possible to
   have several versions of the GIMP installed on the same system.
- the "--help" option will give a full list of the available options

Finally, step 4 tells the user to try "make" and "make install".  If
the user has been running all commands from his (hopefully) non-root
account, it is likely that "make install" will fail because the user
is not allowed to write in /usr/local or whatever $PREFIX she has
chosen.  So the user should be told to type "make", then "su" and then
"make install".

Phew!  That was a long list of suggestions.  Hope this helps...


Gimp-developer mailing list

Reply via email to