Re: Bugs? [Re: Guppi 0.34.5 released]

[Neil J Pilgrim <eennjp electeng leeds ac uk>]

Jon Trowbridge wrote:
> 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.

Well hard-wired defaults should be in place I suppose - I can't see any
way around it. Setting environment variables, as you say, is a major
pain and IMHO is *not* normally the way to go. If anything I would think
that a single contact point from the binary would be better, with the
remaining locations specified at that point. So you'd have a global
config file which is read and specifies the location of .glade files,
plug-ins, etc. That minimises the dependencies upon the executable
without having environment variables (though these could be available
too). Then you could override/add to the settings via a local config
file, in the same manner as /etc/profile and ~/.profile.

> 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...)

Some programs did, but others (noticeably smaller ones) just referred to
the directory they were run from and did everything in an relative-path
way. In linux/UNIX where the 'trees' of each application's directories
are overlaid (from root) this would not really solve the problem.

> 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.

Well surely the way to do this is simply to have a dependency upon
config.h or similar ? I've had a dependency upon my makefile before, so
that when I set an option to have debugging instead of optimising (for
example) that the entire set of objects would have to rebuild...though
this can be *very* annoying if you just make a small change to the
makefile!

Is there an /etc/gnome directory (or similar) ? This would hold general
settings, and a user could specify extra/alternative plug-in directories
in their own .guppirc.

The default global configuration file could be created on compilation
from the PREFIX options. Changes could then be made to this without
requiring a re-compile. This is for when guppi releases are less
frequent ;)

Of course I'm not sure how often you'll need to change the location of
.glade files (for example), but extra configurability can't be bad
(unless it doesn't work out of the box) ?

-- 
Neil