Re: ANN: Build Guide version 2.0.0

[Truls Becken]

Dennis Leeuw wrote:
> > GNUSTEP_*_ROOT variables obsolete with gnustep-make 2.x? Some projects
> > have bugs in their makefiles because the way variables are used have
> > changed over time, and it would help if the build guide didn't
> > encourage use of legacy variables.
>
> yes and no. True if they where not needed, but since I make the users
> compile everything in /usr/GNUstep there needs to be some way to tell
> where everything is.

In many of the places the variables appear, they are used simply to
explain where something is. It should be possible to get rid of them
through rephrasing. When mentioning the defaults database, for
instance, you could say something like "The defaults database is
stored in a non-binary format, by default located in
~/GNUstep/Defaults/.GNUstepDefaults." Schemes such as
"GNUSTEP_USER_ROOT/Library/Colors/" could be replaced by
"Library/Colors/ in the user domain", or something to that effect.

Except for the startup scripts, only two of the code boxes use
variables. The first is the instruction for installing Apps_wrappers.
Here you could simply use a pseudo path which makes it obvious to the
reader that (s)he needs to put in an actual path, like "cp -a *
/path/to/Applications".

The other is the ffcall ./configure at the very end of the guide.
Frankly, this one looks plain wrong to me. ffcall is a general library
and does not follow GNUstep layouts at all. The instruction here
should simply be to install in whatever fashion is standard on the
user's system, with "./configure --prefix=/usr/local" as an example.
Or are the sources on ftp.gnustep.org patched in some way? If so, what
is the rationale for that?

> So there are two approaches (imho):
>
> 1) Set PATH and LD_LIBRARY_PATH (ld.so.conf is linux specific afaik and
> I don't know all the options for other flavours of unix).
>
> 2) source GNUstep.sh and have it that solve the problem.

Yes, configuring PATH and ld.so.conf or LD_LIBRARY_PATH is all that is
needed to run GNUstep applications. That can be done in two lines of a
profile script, much the same way some distros do with other big
packages like KDE/Mozilla/Gnome, as well as binary downloads like
java. Or it can be done by linking GNUstep.sh from a profile
directory. How it's best done probably depends on the system.

Since the profile is read each time I open a new shell, I personally
prefer the first way. The fact that my distro already has a bunch of
similar profile scripts plays a part as well. For the library path I
prefer ld.so.conf because some sort of security thing sometimes kills
LD_LIBRARY_PATH. I guess this is the same issue you suggest 'make
LD_LIBRARY_PATH=$LD_LIBRARY_PATH' as a workaround for in the guide.

Nicola Pero wrote:
> I imagine Truls was referring to your startup scripts where you use
> GNUSTEP_SYSTEM_ROOT and other variables that are considered obsolete
> in gnustep-make v2.0 ... you may want to make your scripts more robust
> (and more future-proof, not to talk encouraging new users/developers
> to use the new, more powerful and general variables) by replacing these
> with non-obsolete variables. ;-)

First of all I was thinking of the general miseducation throughout the
document. The startup scripts are of course of special importance
because people are going to install them and use them on a daily
basis. Then there's the plain fact that things like
$GNUSTEP_SYSTEM_ROOT/Tools are going to break with alternative
layouts.

Dennis Leeuw wrote:
> Nicola Pero wrote:
> > Ideally, your unix build guide might even give people the option of using
> > the gnustep layout or the FHS layout ? :-)
>
> Yep, that's step two. Still not sure how to do that without creating too
> much confusion... it I will add something about that, maybe I put it in
> an Appendix...

Actually, the FHS layout should make things simpler, not harder. With
tools installed in /usr/bin and shared libraries in /usr/lib, you
don't need to configure anything at all to run apps. For compilation
you still need to set GNUSTEP_MAKEFILES, but that's all the make
system needs.

Granted, the domains concept is a little bit easier to explain with
the gnustep layout. On the other hand, every unix system under the sun
uses this concept anyway. It's just that the domains are normally
called /usr, /usr/local and $HOME. So by making that comparsion the
pieces should fit nicely :)

A slightly different organization would be to first explain the
domains, then in the makefile section just mention that
--with-layout=fhs uses the familiar layout and that configuring paths
isn't necessary with this setup. Care must be taken not to make FHS
seem like the more attractive option, though ;)