Menu
▾
▴
gnuplot-beta
|
From: Dr. J. Z. <joh...@ze...> - 2006-06-19 06:45:47
|
Hi,
a big thanks for including the depth patch into gnuplot.
But:
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
this fails when installing gnuplot to any another prefix than /usr/local.
and in config.h:
/* Directory for PostScript prolog and associated files */
#define GNUPLOT_PS_DIR "${prefix}/share/gnuplot/4.1/PostScript"
apparently, prefix should have been expanded there.
Best regards,
--
Johannes
|
|
From: Daniel J S. <dan...@ie...> - 2006-06-19 07:02:09
|
Dr. Johannes Zellner wrote:
> Hi,
>
> a big thanks for including the depth patch into gnuplot.
>
> But:
>
> 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
But that definition is only if GNUPLOT_PS_DIR is not defined, which should probably have been done through the ./configure process. (Although, maybe just complaining that GNUPLOT_PS_DIR is not defined would be just as good.) Something may have gone wrong with your build.
> this fails when installing gnuplot to any another prefix than /usr/local.
Did you use the installation process? Or build and then move the executable somewhere?
>
> and in config.h:
>
> /* Directory for PostScript prolog and associated files */
> #define GNUPLOT_PS_DIR "${prefix}/share/gnuplot/4.1/PostScript"
>
>
> apparently, prefix should have been expanded there.
Or perhaps--as I'm assuming you are using ./prepare prior to ./configure because you must have gotten the latest CVS if you are using the depth patch--it is a problem in your "configure" file. What are your "ac_default_prefix", "exec_prefix", "prefix" and "program_prefix" defined as?
Dan
|
|
From: <tim...@en...> - 2006-06-19 16:35:32
|
Daniel J Sebald wrote:
> Dr. Johannes Zellner wrote:
> =20
>> Hi,
>>
>> a big thanks for including the depth patch into gnuplot.
>>
>> But:
>>
>> 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
>
> But that definition is only if GNUPLOT_PS_DIR is not defined, which sho=
uld probably have been done through the ./configure process. (Although, =
maybe just complaining that GNUPLOT_PS_DIR is not defined would be just a=
s good.) Something may have gone wrong with your build.
>
> =20
True, GNUPLOT_PS_DIR is defined in ./configure.
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 that=20
all custom makefile's do that properly (something else to do before 4.2=20
I think).
> and in config.h:
>
> /* Directory for PostScript prolog and associated files */
> #define GNUPLOT_PS_DIR "${prefix}/share/gnuplot/4.1/PostScript"
>
>
> apparently, prefix should have been expanded there.
> =20
This is a bug, but instead of fixing this bug by another hack with the=20
autotools, I propose to change the whole GNUPLOT_PS_DIR is defined to=20
make it more autotools-compliant :
In configure.in, remove the following lines, because no path should be=20
determined at ./configure time (because you should still be able to do=20
'make --prefix=3D...' or something like that later, and because it needs=20
an ugly hack when --prefix=3D... is not specified by the user) :
dnl location of PostScript prolog and adjunct files
GNUPLOT_PS_DIR=3D"$pkgdatadir/$VERSION_MAJOR/PostScript"
eval GNUPLOT_PS_DIR=3D${GNUPLOT_PS_DIR}
AC_DEFINE_UNQUOTED(GNUPLOT_PS_DIR,"${GNUPLOT_PS_DIR}",
[ Directory for PostScript prolog and associated files ])
and remove also :
AC_SUBST(GNUPLOT_PS_DIR)
In term/Makefile.am, remove the following lines :
# For Unix and MSDOS only
install-data-local:
$(mkinstalldirs) $(DESTDIR)$(GNUPLOT_PS_DIR)
$(INSTALL_DATA) $(srcdir)/PostScript/*.ps=20
$(DESTDIR)$(GNUPLOT_PS_DIR)
uninstall-local:
@$(NORMAL_UNINSTALL)
echo " rm -f $(DESTDIR)$(GNUPLOT_PS_DIR)/*.ps"
rm -f $(DESTDIR)$(GNUPLOT_PS_DIR)/*.ps
In favor of the automake way of doing that :
postscriptdir =3D $(pkgdatadir)/$(VERSION_MAJOR)/PostScript
postscript_DATA =3D 8859-15.ps 8859-1.ps\
8859-2.ps cp1250.ps cp437.ps\
cp850.ps cp852.ps koi8r.ps koi8u.ps\
prologue.ps
And finally, in src/Makefile.am, add to AM_CPPFLAGS :
-DGNUPLOT_PS_DIR=3D\"$(pkgdatadir)/$(VERSION_MAJOR)/PostScript\"
These changes will prevent any problem with the expansions as Johannes=20
experienced (in addition to a lower number of lines !).
Best regards,
Timoth=E9e
|
|
From: Daniel J S. <dan...@ie...> - 2006-06-19 16:46:02
|
Timoth=E9e Lecomte wrote: > True, GNUPLOT_PS_DIR is defined in ./configure. >=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 that=20 > all custom makefile's do that properly (something else to do before 4.2= =20 > I think). You are much more knowledgeable on autotools than I. In any case, I agre= e this sounds like the right approach. Dan |
|
From: <tim...@en...> - 2006-06-19 21:20:57
|
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 that=20
> all custom makefile's do that properly (something else to do before 4.2=
=20
> 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 these=20
platforms, hardcoding a path at compile time is completely wrong.
Two alternatives for them :
- Encode the paths relatively to the binary. Windows has a function for=20
that : GetModuleFileName().
- Include the postscript prologue files at compile time, with something=20
like :
#ifndef GNUPLOT_PS_DIR
static char* prologue[] =3D "
# include PostScript/prologue_ps.h"
}
...
#endif
where prologue_ps.h has been written from prologue.ps so that it can=20
be included (replace '{' by '\{' for example ?).
I vote for the second alternative, which would save a lot of work on=20
each platform. As far as I understand, those Postscript files used to=20
live inside post.trm, but are now separate to make development and=20
corrections easier, right ? Falling back to including them at compile=20
time on some platforms doesn't seem a big drawback then.
Timoth=E9e
|
|
From: <tim...@en...> - 2006-06-19 22:02:13
|
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 |
|
From: Daniel J S. <dan...@ie...> - 2006-06-19 22:44:48
|
Timoth=E9e Lecomte wrote: >>Dan >=20 > 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. >=20 > Anyway, a configuration file only moves the problem to another place :=20 > where is the configuration file located ??? Another hard-coded path ??? Yes, I see your point. Well, I guess then the only reason to have this kind of thing inside the = C code: /* This definition should be in config.h or in the compilation flags */ #ifndef GNUPLOT_PS_DIR #define GNUPLOT_PS_DIR "/usr/local/share/gnuplot/4.1/PostScript" #endif is to allow for someone to compile gnuplot without the aid of the autocon= f/make tools. (I'm unfamiliar with other platform compilation processes.= ) Otherwise, I'd say toss this definition. In any case, perhaps it is wise to allow some means to set this path eith= er at command line or as 'set path term "asdf"'. That way we can put som= ething in the documentation "You don't have to go through the trouble of = recompiling; just find your resource files and type 'set path'." Dan |
|
From: Ethan M. <merritt@u.washington.edu> - 2006-06-19 16:39:52
|
I'm sure glad someone around here understands the autotools,
because I sure don't.
Timoth=E9e, can you make a patch for this change and submit it
to cvs after testing?
Ethan
On Monday 19 June 2006 11:36 am, Timoth=E9e Lecomte wrote:
> Daniel J Sebald wrote:
> > Dr. Johannes Zellner wrote:
> >> Hi,
> >>
> >> a big thanks for including the depth patch into gnuplot.
> >>
> >> But:
> >>
> >> 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
> >
> > But that definition is only if GNUPLOT_PS_DIR is not defined, which
> > should probably have been done through the ./configure process.=20
> > (Although, maybe just complaining that GNUPLOT_PS_DIR is not
> > defined would be just as good.) Something may have gone wrong with
> > your build.
>
> True, GNUPLOT_PS_DIR is defined in ./configure.
>
> I don't have any opinion on what to do when GNUPLOT_PS_DIR is not
> defined (ie when not using ./configure), the best is to make sure
> that all custom makefile's do that properly (something else to do
> before 4.2 I think).
>
> > and in config.h:
> >
> > /* Directory for PostScript prolog and associated files */
> > #define GNUPLOT_PS_DIR "${prefix}/share/gnuplot/4.1/PostScript"
> >
> >
> > apparently, prefix should have been expanded there.
>
> This is a bug, but instead of fixing this bug by another hack with
> the autotools, I propose to change the whole GNUPLOT_PS_DIR is
> defined to make it more autotools-compliant :
>
> In configure.in, remove the following lines, because no path should
> be determined at ./configure time (because you should still be able
> to do 'make --prefix=3D...' or something like that later, and because
> it needs an ugly hack when --prefix=3D... is not specified by the user)
> :
>
> dnl location of PostScript prolog and adjunct files
> GNUPLOT_PS_DIR=3D"$pkgdatadir/$VERSION_MAJOR/PostScript"
> eval GNUPLOT_PS_DIR=3D${GNUPLOT_PS_DIR}
> AC_DEFINE_UNQUOTED(GNUPLOT_PS_DIR,"${GNUPLOT_PS_DIR}",
> [ Directory for PostScript prolog and associated files ])
>
> and remove also :
>
> AC_SUBST(GNUPLOT_PS_DIR)
>
> In term/Makefile.am, remove the following lines :
>
> # For Unix and MSDOS only
> install-data-local:
> $(mkinstalldirs) $(DESTDIR)$(GNUPLOT_PS_DIR)
> $(INSTALL_DATA) $(srcdir)/PostScript/*.ps
> $(DESTDIR)$(GNUPLOT_PS_DIR)
>
> uninstall-local:
> @$(NORMAL_UNINSTALL)
> echo " rm -f $(DESTDIR)$(GNUPLOT_PS_DIR)/*.ps"
> rm -f $(DESTDIR)$(GNUPLOT_PS_DIR)/*.ps
>
> In favor of the automake way of doing that :
>
> postscriptdir =3D $(pkgdatadir)/$(VERSION_MAJOR)/PostScript
> postscript_DATA =3D 8859-15.ps 8859-1.ps\
> 8859-2.ps cp1250.ps cp437.ps\
> cp850.ps cp852.ps koi8r.ps koi8u.ps\
> prologue.ps
>
> And finally, in src/Makefile.am, add to AM_CPPFLAGS :
> =20
> -DGNUPLOT_PS_DIR=3D\"$(pkgdatadir)/$(VERSION_MAJOR)/PostScript\"
>
>
> These changes will prevent any problem with the expansions as
> Johannes experienced (in addition to a lower number of lines !).
>
> Best regards,
>
> Timoth=E9e
>
>
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA
|
|
From: <tim...@en...> - 2006-06-19 16:43:10
|
Ethan Merritt wrote:
> I'm sure glad someone around here understands the autotools,
> because I sure don't.
>
> Timoth=E9e, can you make a patch for this change and submit it
> to cvs after testing?
>
> Ethan
> =20
Sure, I can. (I hope explaining the idea on the list was pedagogical ;-) =
)
Best regards,
Timoth=E9e
>> This is a bug, but instead of fixing this bug by another hack with
>> the autotools, I propose to change the whole GNUPLOT_PS_DIR is
>> defined to make it more autotools-compliant :
>>
>> In configure.in, remove the following lines, because no path should
>> be determined at ./configure time (because you should still be able
>> to do 'make --prefix=3D...' or something like that later, and because
>> it needs an ugly hack when --prefix=3D... is not specified by the user=
)
>> :
>>
>> dnl location of PostScript prolog and adjunct files
>> GNUPLOT_PS_DIR=3D"$pkgdatadir/$VERSION_MAJOR/PostScript"
>> eval GNUPLOT_PS_DIR=3D${GNUPLOT_PS_DIR}
>> AC_DEFINE_UNQUOTED(GNUPLOT_PS_DIR,"${GNUPLOT_PS_DIR}",
>> [ Directory for PostScript prolog and associated files ])
>>
>> and remove also :
>>
>> AC_SUBST(GNUPLOT_PS_DIR)
>>
>> In term/Makefile.am, remove the following lines :
>>
>> # For Unix and MSDOS only
>> install-data-local:
>> $(mkinstalldirs) $(DESTDIR)$(GNUPLOT_PS_DIR)
>> $(INSTALL_DATA) $(srcdir)/PostScript/*.ps
>> $(DESTDIR)$(GNUPLOT_PS_DIR)
>>
>> uninstall-local:
>> @$(NORMAL_UNINSTALL)
>> echo " rm -f $(DESTDIR)$(GNUPLOT_PS_DIR)/*.ps"
>> rm -f $(DESTDIR)$(GNUPLOT_PS_DIR)/*.ps
>>
>> In favor of the automake way of doing that :
>>
>> postscriptdir =3D $(pkgdatadir)/$(VERSION_MAJOR)/PostScript
>> postscript_DATA =3D 8859-15.ps 8859-1.ps\
>> 8859-2.ps cp1250.ps cp437.ps\
>> cp850.ps cp852.ps koi8r.ps koi8u.ps\
>> prologue.ps
>>
>> And finally, in src/Makefile.am, add to AM_CPPFLAGS :
>> =20
>> -DGNUPLOT_PS_DIR=3D\"$(pkgdatadir)/$(VERSION_MAJOR)/PostScript\"
>>
>>
>> These changes will prevent any problem with the expansions as
>> Johannes experienced (in addition to a lower number of lines !).
>>
>> Best regards,
>>
>> Timoth=E9e
>> =20
|
|
From: Daniel J S. <dan...@ie...> - 2006-06-19 17:01:04
|
Timoth=E9e Lecomte wrote: > Ethan Merritt wrote: >=20 >> I'm sure glad someone around here understands the autotools, >> because I sure don't. >> >> Timoth=E9e, can you make a patch for this change and submit it >> to cvs after testing? >> >> Ethan >> =20 >=20 > Sure, I can. (I hope explaining the idea on the list was pedagogical ;-= ) ) That depends on what it is you wanted us to learn. :-) Dan |
|
From: <tim...@en...> - 2006-06-19 17:05:59
|
Daniel J Sebald wrote: > Timoth=E9e Lecomte wrote: > =20 >> Ethan Merritt wrote: >> >> =20 >>> I'm sure glad someone around here understands the autotools, >>> because I sure don't. >>> >>> Timoth=E9e, can you make a patch for this change and submit it >>> to cvs after testing? >>> >>> Ethan >>> =20 >>> =20 >> Sure, I can. (I hope explaining the idea on the list was pedagogical ;= -) ) >> =20 > > That depends on what it is you wanted us to learn. :-) > > Dan > =20 You're right, the success is not guaranteed... :-) TImoth=E9e |
|
From: Daniel J S. <dan...@ie...> - 2006-06-19 21:44:05
|
Timoth=E9e Lecomte wrote: > Timoth=E9e Lecomte wrote: >=20 >>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 that=20 >>all custom makefile's do that properly (something else to do before 4.2= =20 >>I think). >> =20 >=20 > In fact this would be wrong for Windows and probably other platforms=20 > (OS/2 ?), where there are no standard filesystem directories. On these=20 > platforms, hardcoding a path at compile time is completely wrong. Even in unix, propably not the correct method. This sounds like an insta= llation time configuration, something that might best be handled with con= figuration file that gnuplot can search at startup. In fact, one would t= hink that something like autotools would have an automated process for de= aling with such a thing, some macro that indicates a shared resource dire= ctory to be configured when installed. This is of some importance, because otherwise what we are saying is that = from a distribution standpoint there could be dozens if not more unique b= inaries of gnuplot floating about regardless of the configuration options= that the distributers might use. Is that an issue. Dan |
