Re: Bugs? [Re: Guppi 0.34.5 released]

[Jon Trowbridge <trow emccta com>]

On Thu, May 04, 2000 at 06:30:35PM +0100, Neil J Pilgrim wrote:
> Jon Trowbridge wrote:
> > On Thu, May 04, 2000 at 02:42:49PM +0100, Neil J Pilgrim wrote:
> > > A thought: initially I just did a simple './configure' and then 'make';
> > > then I decided I wanted to install locally instead, so did a
> > > './configure --prefix=...' and another make (*no* make clean) followed
> > > by a make install. Perhaps this is the reason ?
> > 
> > That would do it.  If you make clean and re-build, it should work.
> 
> It does :)
> 
> Does this mean that the file locations are hard-coded into the
> executables/libraries ? I suppose that this is the standard way to do
> it, but I always assumed that it was only the 'make install' that
> depended upon the install locations. This is based on the 'compile &
> build it' then 'install it anywhere' principle that comes from a DOS
> background, but again the files are more spread-out on a linux/UNIX
> system I suppose.

Yes, file locations are hard-coded --- or at least the defaults are.
There is the environment variable for plug-ins (and I've added one for
the glade files, based on this thread), but it is really meant to
easily allow for locally-installed plug-ins.

Is this good?  I guess so... it is reasonable that sensible
(hard-wired) defaults should be chosen based on the value of PREFIX.
The only alternatives I can think of is to have hard-wired defaults.
This forces you to set environment variables, or to specify paths in
config files.  But you can already do this in guppi (via
GUPPI_PLUGIN_PATH.  There isn't a way to adjust the search paths from
inside of a .guppirc file, but adding that capability would be
trivial).  I don't know about you, but I always find programs that
*force* me to set an environment variable with a path, despite having
done a plain-vanilla install, to be really annoying.

IIRC, back in the DOS days things were simpler because most programs
would just expect support files to be in a fixed place, like
C:\FOOBAR.  Of course, this was very bad in all sorts of ways.  (Good
luck having two different versions resident on your machine at the
same time...)

The real culprit here is make, actually.  In a perfect world, make
would have seen that the prefix had changed and would have re-built
everything --- but make only detects changes in sources, not in the
build tool or the command lines passed to those tools.  This is a
long-standing problem; maybe the "Software Carpentry" contest will
yield good autoconf/automake/make replacements that will address this.

-JT
 

-- 
GNU/Linux: Free your mind and your OS will follow.