Menu
▾
▴
gnuplot-beta
|
From: <pl...@pi...> - 2007-11-05 09:12:36
|
Hi, running cvs build from about a week back I am getting scaling errors on a simple temp vs time plot. the y data is getting streched to fit the full y range. The cursor displays y values that match the data but the "with lines" plot goes from x axis to top even though the data does not cover that range. my y data goes from 17 - 70 , if I set a yrange 0:80 the plot goes 0-80 , if I let gnuplot set the range it does 10-70 as expected but the plot starts from 10 not 17 as per the data. Unfortunatley I can't check out current cvs because it fails to build without doc 529 ./prepare 530 ./configure --without-tutorial 531 make 532 make install ... make[1]: Leaving directory `/svn/gnuplot/src' Making install in docs make[1]: Entering directory `/svn/gnuplot/docs' ../mkinstalldirs /usr/local/share/gnuplot/4.3 /usr/bin/install -c -m 644 gnuplot.gih /usr/local/share/gnuplot/4.3/gnuplot.gih Creating texinfo Symbol's value as variable is void: load make[1]: *** [gnuplot.texi] Error 255 make[1]: Leaving directory `/svn/gnuplot/docs' make: *** [install-recursive] Error 1 bash-3.2# I got this after running cvs up -P gnuplot on a cvs tree that did compile and install a short while ago. To check again I did a fresh cvs co gnuplot and got the same error. Am I missing a step or has --without-tutorial got an issue? I suspect the plot error was already there but I had not noticed Any suggestions? TIA, Peter. |
|
From: <pl...@pi...> - 2007-11-05 13:09:35
|
On Mon, 05 Nov 2007 10:12:33 +0100, <pl...@pi...> wrote: > Hi, > > running cvs build from about a week back I am getting scaling errors on a > simple temp vs time plot. > > the y data is getting streched to fit the full y range. The cursor > displays y values that match the data but the "with lines" plot goes from > x axis to top even though the data does not cover that range. > > my y data goes from 17 - 70 , if I set a yrange 0:80 the plot goes 0-80 , > if I let gnuplot set the range it does 10-70 as expected but the plot > starts from 10 not 17 as per the data. > appologies, red herring. I had x1y2 slipped by me during a copy-paste, so not y scale problem. Install issue remains. regards, > > Unfortunatley I can't check out current cvs because it fails to build > without doc > > > 529 ./prepare > 530 ./configure --without-tutorial > 531 make > 532 make install > > > ... > > make[1]: Leaving directory `/svn/gnuplot/src' > Making install in docs > make[1]: Entering directory `/svn/gnuplot/docs' > ../mkinstalldirs /usr/local/share/gnuplot/4.3 > /usr/bin/install -c -m 644 gnuplot.gih > /usr/local/share/gnuplot/4.3/gnuplot.gih > Creating texinfo > Symbol's value as variable is void: load > make[1]: *** [gnuplot.texi] Error 255 > make[1]: Leaving directory `/svn/gnuplot/docs' > make: *** [install-recursive] Error 1 > bash-3.2# > > > I got this after running cvs up -P gnuplot on a cvs tree that did > compile and install a short while ago. To check again I did a fresh cvs > co > gnuplot and got the same error. > > Am I missing a step or has --without-tutorial got an issue? > > I suspect the plot error was already there but I had not noticed > > Any suggestions? > > TIA, Peter. > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > gnuplot-beta mailing list > gnu...@li... > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta > |
|
From: Ethan A M. <merritt@u.washington.edu> - 2007-11-05 14:58:45
|
On Monday 05 November 2007 01:12, pl...@pi... wrote:
>
> Unfortunatley I can't check out current cvs because it fails to build
> without doc
>
>
> 529 ./prepare
> 530 ./configure --without-tutorial
> 531 make
> 532 make install
--without-tutorial has nothing to do with gnuplot.texi
It is for of the gnu info system, not the TeX documentation.
> make[1]: Leaving directory `/svn/gnuplot/src'
> Making install in docs
> make[1]: Entering directory `/svn/gnuplot/docs'
> ../mkinstalldirs /usr/local/share/gnuplot/4.3
> /usr/bin/install -c -m 644 gnuplot.gih
> /usr/local/share/gnuplot/4.3/gnuplot.gih
> Creating texinfo
> Symbol's value as variable is void: load
> make[1]: *** [gnuplot.texi] Error 255
> make[1]: Leaving directory `/svn/gnuplot/docs'
> make: *** [install-recursive] Error 1
> bash-3.2#
What version of Emacs is it trying to use?
I applied a patch last week that supposedly accommodated
more recent versions of Xemacs. It worked for me here,
but I suppose it could be the culprit.
Try reverting this change:
2007-10-30 Christian Faulhammer (v-...@us...)
* docs/doc2texi.el: Gentoo patch to allow for changed handling of
newlines in up-coming version of XEmacs. Needed in order to
regenerate gnuplot.texi on such a system.
Bug #1822610
I am convinced that the texinfo system is far more trouble
than it is worth. Perhaps it should be removed from the
default build. We distribute a copy of gnuplot.texi anyway,
so there's not normally a need for the user to rebuild it.
--
Ethan A Merritt
|
|
From: <pl...@pi...> - 2007-11-05 15:54:00
|
On Mon, 05 Nov 2007 15:58:45 +0100, Ethan A Merritt <merritt@u.washington.edu> wrote: > On Monday 05 November 2007 01:12, pl...@pi... wrote: >> >> Unfortunatley I can't check out current cvs because it fails to build >> without doc >> >> >> 529 ./prepare >> 530 ./configure --without-tutorial >> 531 make >> 532 make install > > --without-tutorial has nothing to do with gnuplot.texi > It is for of the gnu info system, not the TeX documentation. > > >> make[1]: Leaving directory `/svn/gnuplot/src' >> Making install in docs >> make[1]: Entering directory `/svn/gnuplot/docs' >> ../mkinstalldirs /usr/local/share/gnuplot/4.3 >> /usr/bin/install -c -m 644 gnuplot.gih >> /usr/local/share/gnuplot/4.3/gnuplot.gih >> Creating texinfo >> Symbol's value as variable is void: load >> make[1]: *** [gnuplot.texi] Error 255 >> make[1]: Leaving directory `/svn/gnuplot/docs' >> make: *** [install-recursive] Error 1 >> bash-3.2# > > What version of Emacs is it trying to use? > emacs-22.1-r1 on Gentoo ~x86 > I applied a patch last week that supposedly accommodated > more recent versions of Xemacs. It worked for me here, > but I suppose it could be the culprit. > Try reverting this change: What does that bug no. refer to? Where's the patch? > > 2007-10-30 Christian Faulhammer (v-...@us...) > * docs/doc2texi.el: Gentoo patch to allow for changed handling of > newlines in up-coming version of XEmacs. Needed in order to > regenerate gnuplot.texi on such a system. > Bug #1822610 > > I am convinced that the texinfo system is far more trouble > than it is worth. I'll second that ;) > Perhaps it should be removed from the > default build. We distribute a copy of gnuplot.texi anyway, > so there's not normally a need for the user to rebuild it. > It's also a huge dep. pkg IRCC it's about an order of magnitude bigger than gnuplot! I had some trouble compiling tetex which was needed for gnuplot and had to do some digging to avoid it. If it can be taken out of default it seems like a good move. Wasn't there another option like --without-doc that I don't seem to see any more? Thanks, Peter. |
|
From: Ethan M. <merritt@u.washington.edu> - 2007-11-05 17:02:35
|
On Monday 05 November 2007 07:54, pl...@pi... wrote: > > What version of Emacs is it trying to use? > > > > emacs-22.1-r1 > on Gentoo ~x86 > > > I applied a patch last week that supposedly accommodated > > more recent versions of Xemacs. It worked for me here, > > but I suppose it could be the culprit. > > Try reverting this change: > > What does that bug no. refer to? Where's the patch? Gentoo bug: http://bugs.gentoo.org/show_bug.cgi?id=194216 Gnuplot report: http://sourceforge.net/tracker/index.php?func=detail&aid=1822610&group_id=2055&atid=102055 You obviously don't really care about gnuplot.texi. I suggest you just do: touch .../docs/gnuplot.texi after that the make system should ignore it. In fact, now that I think about it, that's probably why you are just noticing the problem now. Because I applied that gentoo patch, one of the dependencies in the source tree is now newer than gnuplot.texi. So "make" is trying to rebuild it even though nothing has really changed. Just do the "touch" and forget it. > > 2007-10-30 Christian Faulhammer (v-...@us...) > > * docs/doc2texi.el: Gentoo patch to allow for changed handling of > > newlines in up-coming version of XEmacs. Needed in order to > > regenerate gnuplot.texi on such a system. > > Bug #1822610 > > > > I am convinced that the texinfo system is far more trouble > > than it is worth. > > I'll second that ;) > > > Perhaps it should be removed from the > > default build. We distribute a copy of gnuplot.texi anyway, > > so there's not normally a need for the user to rebuild it. > > > > It's also a huge dep. pkg IRCC it's about an order of magnitude bigger > than gnuplot! I had some trouble compiling tetex You are still confusing TeX (tetex) and gnu info. Gnu info is only large because of emacs. I find both info and emacs unusable, but I keep emacs installed on one machine so that I can regenerate gnuplot.texi from time to time :-) But the really huge package is TeX (tetex), which is something else altogether. -- Ethan A Merritt |
|
From: <pl...@pi...> - 2007-11-06 08:48:17
|
On Mon, 05 Nov 2007 18:02:32 +0100, Ethan Merritt <merritt@u.washington.edu> wrote: > >> > I am convinced that the texinfo system is far more trouble >> > than it is worth. >> >> I'll second that >> >> > Perhaps it should be removed from the >> > default build. We distribute a copy of gnuplot.texi anyway, >> > so there's not normally a need for the user to rebuild it. >> > >> >> It's also a huge dep. pkg IRCC it's about an order of magnitude bigger >> than gnuplot! I had some trouble compiling tetex > You are still confusing TeX (tetex) and gnu info. > Gnu info is only large because of emacs. I find both info and emacs > unusable, but I keep emacs installed on one machine so that I can > regenerate gnuplot.texi from time to time > But the really huge package is TeX (tetex), which is something else > altogether. > Many thanks Ethan, the touch sorted out my installation problem. Is there a way to remove these heavy dependancies? It seems you are about as keen on emacs as I am and tetex is a monster. One of the very appealing features of gnuplot is that it's a fully featured but lightwieght plotting tool. It seems a bit incongruous to have heavy deps for what seem to be accessory features. I'm using gnuplot on ARM embedded. At the moment it's running on a full debian image via nfs but when it goes onboard cruft will not be an option. BTW I was very favourably surprised how quickly it ran on that arch. A credit to both the power/wieght ratio of the ARM and the power/volume ratio of gnuplot. Kudos to all concerned. ;) |
|
From: Ethan M. <merritt@u.washington.edu> - 2007-11-06 19:55:53
|
On Tuesday 06 November 2007 00:35, pl...@pi... wrote:
>
> Is there a way to remove these heavy dependancies?
> It seems you are about as keen on emacs as I am and tetex is a monster.
They are not really dependencies, except in the sense that if the
autoconfigure script finds them installed it may try to use them.
Certainly once the program is built it cares nothing about either
emacs or TeX.
Or at least that's the intent. I've had repeated troubles with the
emacs test (it tries to write to a system directory, which means
normal users get an error message). I'm not aware of any problems
with building on a system without TeX installed. Then again, I'm
a TeX user so most of my machines have it :-)
> I'm using gnuplot on ARM embedded. At the moment it's running on a full
> debian image via nfs but when it goes onboard cruft will not be an option.
The major consideration in building a lightweight gnuplot executable
is which terminal drivers to include. But the LaTeX terminals are pretty
small, so disabling them isn't likely to save any space unless you disable
PostScript support as well. I made a chart 2 years ago for version 4.0
http://skuld.bmsc.washington.edu/people/merritt/gnuplot/index.html#bloat
I should update it against current CVS.
--
Ethan A Merritt
|
|
From: <pl...@pi...> - 2007-11-07 03:45:20
|
On Tue, 06 Nov 2007 20:55:50 +0100, Ethan Merritt <merritt@u.washington.edu> wrote: > >> I'm using gnuplot on ARM embedded. At the moment it's running on a full >> debian image via nfs but when it goes onboard cruft will not be an >> option. > The major consideration in building a lightweight gnuplot executable > is which terminal drivers to include. But the LaTeX terminals are pretty > small, so disabling them isn't likely to save any space unless you > disable > PostScript support as well. I made a chart 2 years ago for version 4.0 > http://skuld.bmsc.washington.edu/people/merritt/gnuplot/index.html#bloat > I should update it against current CVS. Thanks, that new info will be very useful. Sounds like my ./configure arg list is going to be rather long! Is there a more concise way to get a bare bones gnuplot --without-terminals and just add in the one that I need , svg? thx |
|
From: Ethan A M. <merritt@u.washington.edu> - 2007-11-07 06:47:03
|
On Tuesday 06 November 2007 19:33, pl...@pi... wrote: > On Tue, 06 Nov 2007 20:55:50 +0100, Ethan Merritt > <merritt@u.washington.edu> wrote: > > > > >> I'm using gnuplot on ARM embedded. At the moment it's running on a full > >> debian image via nfs but when it goes onboard cruft will not be an > >> option. > > The major consideration in building a lightweight gnuplot executable > > is which terminal drivers to include. But the LaTeX terminals are pretty > > small, so disabling them isn't likely to save any space unless you > > disable > > PostScript support as well. I made a chart 2 years ago for version 4.0 > > http://skuld.bmsc.washington.edu/people/merritt/gnuplot/index.html#bloat > > I should update it against current CVS. > > > Thanks, that new info will be very useful. Sounds like my ./configure arg > list is going to be rather long! > > Is there a more concise way to get a bare bones gnuplot > --without-terminals and just add in the one that I need , svg? Interesting question. I see that it's hard to turn off a lot of the auto-detected stuff. For instance, doing ./configure --disable-wxwidgets --disable-cairo nevertheless detects and links against the cairo and pango libraries, even though it doesn't actually build the wxt or cairo terminals. Stupid. And just removing the library references from the Makefile doesn't work either, because it still tries to compile gp_cairo.c. Not that gp_cairo.o is very big, but it's annoying. Here's my go at it: %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% ./configure --without-x --without-gd \ --disable-wxwidgets --disable-cairo --disable-mouse echo '#include "svg.trm"' > src/term.h echo '#include "estimate.trm"' >> term.h [Manually hack src/Makefile to remove all the cairo/pango related library definitions, and the gp_cairo.o target] make size gnuplot text data bss dec hex filename 631437 30580 14432 676449 a5261 gnuplot ldd gnuplot linux-gate.so.1 => (0xffffe000) libreadline.so.5 => /lib/libreadline.so.5 (0xb7f2d000) libncurses.so.5 => /lib/libncurses.so.5 (0xb7ee8000) libz.so.1 => /lib/libz.so.1 (0xb7ed5000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7cfb000) libm.so.6 => /lib/tls/libm.so.6 (0xb7cd6000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7ccb000) libc.so.6 => /lib/tls/libc.so.6 (0xb7b9c000) libdl.so.2 => /lib/libdl.so.2 (0xb7b98000) /lib/ld-linux.so.2 (0xb7f75000) ./gnuplot gnuplot> set term Available terminal types: svg W3C Scalable Vector Graphics driver unknown Unknown terminal type - not a plotting device %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Are you sure you don't want at least a few more output options? svg by itself is pretty horrible for pm3d or image plots. Normally if you're creating svg pages, you would embed links to png images instead. Adding libgd would get you png, jpeg and gif (including animated gif). Although if you want nice fonts then it'll drag in libfreetype, which isn't so lightweight. By the time you have libgd, libpng, libfreetype, that's probably an additional hit equal in size to gnuplot itself. Of course those are shared libraries, so if you're using them for something else already they are essentially free. And it's probably worth including dumb.trm, if only for debugging. Will there be a user interface of any sort, or will it be entirely script-driven? -- Ethan A Merritt |
|
From: Ethan A M. <merritt@u.washington.edu> - 2007-11-07 07:13:06
|
On Tuesday 06 November 2007 21:53, Ethan A Merritt wrote:
> For instance, doing
> ./configure --disable-wxwidgets --disable-cairo
> nevertheless detects and links against the cairo and pango libraries, even
> though it doesn't actually build the wxt or cairo terminals.
False alarm. It should have been
./configure --disable-wxwidgets --without-cairo
It's a pity that enable/disable and with/without aren't treated
as synonyms. How is anyone supposed to remember which one goes
with which option?
--
Ethan A Merritt
|
|
From: <pl...@pi...> - 2007-11-07 10:52:32
|
On Wed, 07 Nov 2007 06:53:57 +0100, Ethan A Merritt = <merritt@u.washington.edu> wrote: > On Tuesday 06 November 2007 19:33, pl...@pi... wrote: >> On Tue, 06 Nov 2007 20:55:50 +0100, Ethan Merritt >> <merritt@u.washington.edu> wrote: >> >> > >> >> I'm using gnuplot on ARM embedded. At the moment it's running on a= = >> full >> >> debian image via nfs but when it goes onboard cruft will not be an= >> >> option. >> > The major consideration in building a lightweight gnuplot executabl= e >> > is which terminal drivers to include. But the LaTeX terminals are = = >> pretty >> > small, so disabling them isn't likely to save any space unless you >> > disable >> > PostScript support as well. I made a chart 2 years ago for version= = >> 4.0 >> > = >> http://skuld.bmsc.washington.edu/people/merritt/gnuplot/index.html#bl= oat >> > I should update it against current CVS. >> >> >> Thanks, that new info will be very useful. Sounds like my ./configure= = >> arg >> list is going to be rather long! >> >> Is there a more concise way to get a bare bones gnuplot >> --without-terminals and just add in the one that I need , svg? > > Interesting question. > I see that it's hard to turn off a lot of the auto-detected stuff. > For instance, doing > ./configure --disable-wxwidgets --disable-cairo > nevertheless detects and links against the cairo and pango libraries, = = > even > though it doesn't actually build the wxt or cairo terminals. Stupid. > And just removing the library references from the Makefile doesn't wor= k > either, because it still tries to compile gp_cairo.c. Not that = > gp_cairo.o > is very big, but it's annoying. > > > Here's my go at it: > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= %%% > ./configure --without-x --without-gd \ > --disable-wxwidgets --disable-cairo --disable-mouse > echo '#include "svg.trm"' > src/term.h > echo '#include "estimate.trm"' >> term.h > [Manually hack src/Makefile to remove all the cairo/pango related libr= ary > definitions, and the gp_cairo.o target] > make > > size gnuplot > text data bss dec hex filename > 631437 30580 14432 676449 a5261 gnuplot > > ldd gnuplot > linux-gate.so.1 =3D> (0xffffe000) > libreadline.so.5 =3D> /lib/libreadline.so.5 (0xb7f2d000) > libncurses.so.5 =3D> /lib/libncurses.so.5 (0xb7ee8000) > libz.so.1 =3D> /lib/libz.so.1 (0xb7ed5000) > libstdc++.so.6 =3D> /usr/lib/libstdc++.so.6 (0xb7cfb000) > libm.so.6 =3D> /lib/tls/libm.so.6 (0xb7cd6000) > libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0xb7ccb000) > libc.so.6 =3D> /lib/tls/libc.so.6 (0xb7b9c000) > libdl.so.2 =3D> /lib/libdl.so.2 (0xb7b98000) > /lib/ld-linux.so.2 (0xb7f75000) > > ./gnuplot > gnuplot> set term > Available terminal types: > svg W3C Scalable Vector Graphics driver > unknown Unknown terminal type - not a plotting device > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= %%%% > > Are you sure you don't want at least a few more output options? > > svg by itself is pretty horrible for pm3d or image plots. > Normally if you're creating svg pages, you would embed links to png > images instead. > > Adding libgd would get you png, jpeg and gif (including animated gif).= > Although if you want nice fonts then it'll drag in libfreetype, which > isn't so lightweight. By the time you have libgd, libpng, libfreetype= , > that's probably an additional hit equal in size to gnuplot itself. > Of course those are shared libraries, so if you're using them for > something else already they are essentially free. > > And it's probably worth including dumb.trm, if only for debugging. > > Will there be a user interface of any sort, or will it be entirely > script-driven? > > Thanks for all the detail, it looks like I should get quite close to wha= t = I want with all that. The application is a headless hardware monitoring system. My aim is to = provide continual realtime data viewing with svg and apache so in = principal that one terminal is enough. SVG seems ideally suited to plots= = since it allows zooming in for detail and is way lighter than png. Since svg rendering is getting pretty stable on Opera, konqueror and = Firefox I think this will do the job. Most of it will be automatic updates running off cron or triggered by th= e = monitoring software. I'm not too close to installing on the board yet, but I'm running native= = ARM over nfs during the development stage. I'll get back to this in deta= il = once I get to hone all this down to fit on the board. Many thanks for your help. Peter. |
|
From: <HBB...@t-...> - 2007-11-07 20:03:33
|
Ethan A Merritt wrote:
> On Tuesday 06 November 2007 21:53, Ethan A Merritt wrote:
>> For instance, doing
>> ./configure --disable-wxwidgets --disable-cairo
>> nevertheless detects and links against the cairo and pango libraries, even
>> though it doesn't actually build the wxt or cairo terminals.
>
> False alarm. It should have been
> ./configure --disable-wxwidgets --without-cairo
>
> It's a pity that enable/disable and with/without aren't treated
> as synonyms. How is anyone supposed to remember which one goes
> with which option?
Not at all. Just like nobody is supposed to remember the list of
available --enable/--disable/--with{,out} options. That's what
./configure --help is for (./configure --help=short if you already know
the generic configure options).
|
|
From: <pl...@pi...> - 2007-11-07 23:34:58
|
On Wed, 07 Nov 2007 21:03:04 +0100, Hans-Bernhard Bröker
<HBB...@t-...> wrote:
> Ethan A Merritt wrote:
>> On Tuesday 06 November 2007 21:53, Ethan A Merritt wrote:
>>> For instance, doing
>>> ./configure --disable-wxwidgets --disable-cairo
>>> nevertheless detects and links against the cairo and pango libraries,
>>> even
>>> though it doesn't actually build the wxt or cairo terminals.
>>
>> False alarm. It should have been
>> ./configure --disable-wxwidgets --without-cairo
>>
>> It's a pity that enable/disable and with/without aren't treated
>> as synonyms. How is anyone supposed to remember which one goes
>> with which option?
>
> Not at all. Just like nobody is supposed to remember the list of
> available --enable/--disable/--with{,out} options. That's what
> ./configure --help is for (./configure --help=short if you already know
> the generic configure options).
>
So no-one is likely to remember the whole list, but accepting we can
remember a few we need to include/exclude it would be nice not add to the
burden with apparently arbitary on/off option names. Is there a feature
here we are missing the point of?
Is there a good reason they are not synonymous?
thx.
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>
|
|
From: Allin C. <cot...@wf...> - 2007-11-08 01:17:16
|
On Thu, 8 Nov 2007, pl...@pi... quoted:
> >> It's a pity that enable/disable and with/without aren't treated
> >> as synonyms. How is anyone supposed to remember which one goes
> >> with which option?
> >
> > Not at all. Just like nobody is supposed to remember the list of
> > available --enable/--disable/--with{,out} options. That's what
> > ./configure --help is for (./configure --help=short if you already know
> > the generic configure options).
and wrote:
>
> So no-one is likely to remember the whole list, but accepting we
> can remember a few we need to include/exclude it would be nice
> not add to the burden with apparently arbitary on/off option
> names. Is there a feature here we are missing the point of?
I'm not sure this is totally compelling, but I think the
traditional distinction in the autoconf context is
* enable/disable is a simple binary feature toggle
* with/without implies inclusion or not of functionality provided
by a third-party library or app, and implies an optional
parameter to "with", namely the path to the third-party
something, as in
--with-ssl=/opt/openssl
Allin Cottrell
|
|
From: <pl...@pi...> - 2007-11-08 19:42:36
|
On Thu, 08 Nov 2007 02:16:22 +0100, Allin Cottrell <cot...@wf...> =
wrote:
> On Thu, 8 Nov 2007, pl...@pi... quoted:
>
>> >> It's a pity that enable/disable and with/without aren't treated
>> >> as synonyms. How is anyone supposed to remember which one goes
>> >> with which option?
>> >
>> > Not at all. Just like nobody is supposed to remember the list of
>> > available --enable/--disable/--with{,out} options. That's what
>> > ./configure --help is for (./configure --help=3Dshort if you alread=
y =
>> know
>> > the generic configure options).
>
> and wrote:
>>
>> So no-one is likely to remember the whole list, but accepting we
>> can remember a few we need to include/exclude it would be nice
>> not add to the burden with apparently arbitary on/off option
>> names. Is there a feature here we are missing the point of?
>
> I'm not sure this is totally compelling, but I think the
> traditional distinction in the autoconf context is
>
> * enable/disable is a simple binary feature toggle
>
> * with/without implies inclusion or not of functionality provided
> by a third-party library or app, and implies an optional
> parameter to "with", namely the path to the third-party
> something, as in
>
> --with-ssl=3D/opt/openssl
>
> Allin Cottrell
>
Thanks for that explaination, that does go someway to explaining the =
difference but does not seem to apply generally to gnuplot since several=
=
"with" options are not due to external deps.
non exhaustive list:
--with-cwdrc check current directory for .gnuplot file,
normally disabled for security reasons
--with-row-help format help and subtopic tables by row (defau=
lt)
--without-row-help format help and subtopic tables by column
It may help to remember some cases though.
Thx.
|
