Re: Proposal: an addition to glib for getting the absolute path of the current binary.

[Enrico Weigelt <weigelt metux de>]

* Mike Hearn <mike navi cx> [2004-04-12 14:17:45 +0100]:

> On Fri, 09 Apr 2004 21:36:39 +0200, Enrico Weigelt wrote:
> > What exactly is the problem ?
> 
> Typically loading data files.

Where could the binary location help here ?
Either the data is stored somewhere under the user's homedir or
some global location. But these locations normally have nothing to do
with the binary location and thus are either compiled-in or catched
from an environment variable or perhaps some kind of global config file.

> > Why not let the machine do the recompile work ?
> 
> Many users do not wish to compile their own software. This is especially
> true on server systems which should not have developer tools installed at
> all for security reasons.
Did I say anything about where the compilation process runs ?!
The Admin just says what packages he wants and which feature should 
be enabled in them. Its then the job of the machine to get the right
binary packages installed on the system. The package source can be a
local or remote repositiory or and buildfarm somewhere on the net
(probably on the local machine or perhaps one someone's workstation)

> > What exactly do you need it for ?
> > 
> > You probably need to find some resource files, configuration, etc. Where
> > could the location of the binary help ?
> 
> Programs such as Gaim and the Gimp already use the Win32 version of this
> API, so the need is clearly there. They work backwards from the absolute
> path of the binary to get the share/whatever directory for data files,
> normally.
Fetching the data location from the binary location is in general a very 
bad idea. Yes, some windows applications tend to install themselves under
some directy, which the user has to type in before installation, and also
stores user-data under this directory. But this is principle mis-design
and should not be supported by toolkits like glib.

<snip>
> > Could this please be located in another library, and not glib.so /
> > glib.h ? Its already too big.
> 
> The Gimp developers specifically requested it be put in glib, as it is
> their portability layer and is already used for such things.
Compatibility Layer ?

This reminds me on NPWL (netscape portable windows library!) - inherently 
the name shows the misdesign behind. Abstraction should always be done
alongs the borders of functionality, not just by wrapping around 
incompatible functions.

You probably dont want glib to degenerate to such kind of "compatibilty layer".


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT services

  phone:     +49 36207 519931         www:       http://www.metux.de/
  fax:       +49 36207 519932         email:     contact metux de
  cellphone: +49 174 7066481
---------------------------------------------------------------------
   -- DSL-Zugang ab 0 Euro. -- statische IP -- UUCP -- Hosting --
---------------------------------------------------------------------