Re: thanks and rant

[<tim...@en...>]

Daniel J Sebald wrote:
> Timoth=E9e Lecomte wrote:
>> Timoth=E9e Lecomte wrote:
>>
>>> Daniel J Sebald wrote:
>>> =20
>>>
>>>> Dr. Johannes Zellner wrote:
>>>> =20
>>>>  =20
>>>>> in trm/post.trm there's a really ugly hardcoded path:
>>>>>
>>>>> #ifndef GNUPLOT_PS_DIR
>>>>> #define GNUPLOT_PS_DIR "/usr/local/share/gnuplot/4.1/PostScript"
>>>>> #endif
>>>>>     =20
>>>
>>> (...)
>>>
>>> I don't have any opinion on what to do when GNUPLOT_PS_DIR is not=20
>>> defined (ie when not using ./configure), the best is to make sure=20
>>> that all custom makefile's do that properly (something else to do=20
>>> before 4.2 I think).
>>> =20
>>
>> In fact this would be wrong for Windows and probably other platforms=20
>> (OS/2 ?), where there are no standard filesystem directories. On=20
>> these platforms, hardcoding a path at compile time is completely wrong.
>
> Even in unix, propably not the correct method.  This sounds like an=20
> installation time configuration, something that might best be handled=20
> with configuration file that gnuplot can search at startup.  In fact,=20
> one would think that something like autotools would have an automated=20
> process for dealing with such a thing, some macro that indicates a=20
> shared resource directory to be configured when installed.
>
> This is of some importance, because otherwise what we are saying is=20
> that from a distribution standpoint there could be dozens if not more=20
> unique binaries of gnuplot floating about regardless of the=20
> configuration options that the distributers might use.  Is that an issu=
e.
>
> Dan
To some extent, this run-time configuration is possible with the=20
environment variable GNUPLOT_PS_DIR. Ethan has written the code so that=20
it looks for this variable first, as it is done to find the gnuplot_x11=20
executable (X11_DRIVER_DIR) for example.

Anyway, a configuration file only moves the problem to another place :=20
where is the configuration file located ??? Another hard-coded path ???

In Unix, I can see two standard ways to install a program. The first is=20
through the "configure/make/make install" steps, where the installation=20
path is determined at compile time. Installing manually somewhere else=20
is possible but you have to play with the environment variables. The=20
second one is by installing a binary package. Can you choose where to=20
install a .deb or .rpm package ? I don't think so, but I may be wrong.

The nightmare of binary relocation is detailed in the autopackage doc :=20
http://autopackage.org/docs/devguide/ch05.html
Autopackage is a set of tools to create distribution-neutral and=20
relocatable packages. Although it seems a noble objective, it also seems=20
very difficult to achieve. Moreover this project only deals with linux,=20
but not for all UNIX. I don't think we should spend time on making=20
gnuplot relocatable, but rely on the autotools/GNU way.

Timoth=E9e