Menu
▾
▴
gnuplot-beta
|
From: Dmitri A. S. <das...@gm...> - 2006-07-25 18:00:04
|
Today's cvs on Fedora Core 5 (x86_64). ./prepare CFLAGS="-O3 -m64 -pipe" ./configure --with-readline=gnu make make[2]: Leaving directory `/home/dima/src/gnuplot/demo' Making all in tutorial make[2]: Entering directory `/home/dima/src/gnuplot/tutorial' Expected X11 driver: /usr/local/libexec/gnuplot/4.1/gnuplot_x11 Exec failed: No such file or directory See 'help x11' for more details make[2]: *** [eg1.tex] Error 141 make[2]: Leaving directory `/home/dima/src/gnuplot/tutorial' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/dima/src/gnuplot' make: *** [all] Error 2 (Of course it worked on the computer that had an older version installed in /usr/local ...) Sincerely, Dmitri. -- |
|
From: <br...@ph...> - 2006-07-25 20:48:54
|
Dmitri A. Sergatskov wrote: > make[2]: Leaving directory `/home/dima/src/gnuplot/demo' > Making all in tutorial > make[2]: Entering directory `/home/dima/src/gnuplot/tutorial' > Expected X11 driver: /usr/local/libexec/gnuplot/4.1/gnuplot_x11 > Exec failed: No such file or directory > See 'help x11' for more details gnuplot_x11 isn't even supposed to be started by this run of gnuplot. And it isn't -- I know, because I have no /usr/local/libexec/gnuplot/$version/gnuplot_x11 for the binary I've just tested, and it did work. In other words, it's not the exec of gnuplot_x11 that failed you. You'll have to dig deeper. I think you'll have to either reproduce the gnuplot runs done in the tutorial directory inside a debugger, or do likewise with 'strace', to find out *which* exec() failed. |
|
From: Daniel J S. <dan...@ie...> - 2006-07-25 20:55:56
|
Hans-Bernhard Br=F6ker wrote: > Dmitri A. Sergatskov wrote: >=20 >>make[2]: Leaving directory `/home/dima/src/gnuplot/demo' >>Making all in tutorial >>make[2]: Entering directory `/home/dima/src/gnuplot/tutorial' >>Expected X11 driver: /usr/local/libexec/gnuplot/4.1/gnuplot_x11 >>Exec failed: No such file or directory >>See 'help x11' for more details Hans, It appears that my email didn't make it through the gnuplot-beta server. = I'll forward... |
|
From: <tim...@en...> - 2006-07-25 21:25:59
|
Hans-Bernhard Br=F6ker wrote: > Dmitri A. Sergatskov wrote: > =20 >> make[2]: Leaving directory `/home/dima/src/gnuplot/demo' >> Making all in tutorial >> make[2]: Entering directory `/home/dima/src/gnuplot/tutorial' >> Expected X11 driver: /usr/local/libexec/gnuplot/4.1/gnuplot_x11 >> Exec failed: No such file or directory >> See 'help x11' for more details >> =20 > > gnuplot_x11 isn't even supposed to be started by this run of gnuplot. > =20 In addition to the explanation in my previous mail, here is the patch=20 that caused this behaviour : http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D1509033&grou= p_id=3D2055&atid=3D102055 Best regards, Timoth=E9e |
|
From: Petr M. <mi...@ph...> - 2006-07-28 14:42:43
|
> Dmitri A. Sergatskov wrote: >> make[2]: Leaving directory `/home/dima/src/gnuplot/demo' >> Making all in tutorial >> make[2]: Entering directory `/home/dima/src/gnuplot/tutorial' >> Expected X11 driver: /usr/local/libexec/gnuplot/4.1/gnuplot_x11 >> Exec failed: No such file or directory >> See 'help x11' for more details > > gnuplot_x11 isn't even supposed to be started by this run of gnuplot. > And it isn't -- I know, because I have no > /usr/local/libexec/gnuplot/$version/gnuplot_x11 for the binary I've just > tested, and it did work. In other words, it's not the exec of > gnuplot_x11 that failed you. You'll have to dig deeper. Cannot it happen due to "set term x11" in $HOME/.gnuplot? Gnuplot should avoid to read this file during "make". --- PM |
|
From: Dmitri A. S. <das...@gm...> - 2006-07-27 00:11:39
|
On 7/25/06, Petr Mikulik <mi...@ph...> wrote: > Cannot it happen due to "set term x11" in $HOME/.gnuplot? Gnuplot should > avoid to read this file during "make". > my .gnuplot has only "set mouse" > --- > PM > Dmitri. -- |
|
From: <br...@ph...> - 2006-07-26 20:48:23
|
Petr Mikulik wrote: > Cannot it happen due to "set term x11" in $HOME/.gnuplot? No. gnuplot_x11 isn't actually needed until the plot window is about to be actually opened, i.e. the first 'plot', 'splot' or 'set multiplot' with 'set term x11' open. tutorial/Makefile never opens an X11 window, so it *cannot* need gnuplot_x11. I can accept that people want it to complain about not finding it, even long before the terminal it's actually needed, because that signals a broken gnuplot installation. But it can't *fail* because it can't find it. |
|
From: <tim...@en...> - 2006-07-26 21:01:00
Attachments:
tutdirs.diff
|
Dmitri A. Sergatskov wrote: > Today's cvs on Fedora Core 5 (x86_64). > ./prepare > CFLAGS=3D"-O3 -m64 -pipe" > ./configure --with-readline=3Dgnu > make > make[2]: Leaving directory `/home/dima/src/gnuplot/demo' > Making all in tutorial > make[2]: Entering directory `/home/dima/src/gnuplot/tutorial' > Expected X11 driver: /usr/local/libexec/gnuplot/4.1/gnuplot_x11 > Exec failed: No such file or directory > See 'help x11' for more details > make[2]: *** [eg1.tex] Error 141 > make[2]: Leaving directory `/home/dima/src/gnuplot/tutorial' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/home/dima/src/gnuplot' > make: *** [all] Error 2 > > (Of course it worked on the computer that had an older version > installed in /usr/local ...) > > Sincerely, > > Dmitri. > =20 Hi Dmitri, Can you please try the attached patch ? I think this got broken when we added the call to term->options() in=20 term.c:1729:init_terminal(), to fix the use of GNUTERM for all terminals=20 at once (otherwise some of them would no initialize some of their=20 values). As a consequence, when x11 is compiled in, gnuplot initializes=20 it by launching gnuplot_x11 even if the script does not actually uses=20 the x11 terminal. As per the imprecision on term->fillbox() that we=20 discussed some times ago, some drivers assume that term->options() will=20 be always called before term->init(), whereas others don't and take more=20 care. The fix in init_terminal() was for the former, while the latter=20 (as X11) lose part of their flexibility in the game... Best regards, Timoth=E9e |
|
From: Dmitri A. S. <das...@gm...> - 2006-07-25 21:04:46
|
On 7/25/06, Timoth=E9e Lecomte <tim...@en...> wrote: > > Can you please try the attached patch ? > > > Timoth=E9e > > It worked. Thanks! Dmitri. -- |
|
From: Ethan A M. <merritt@u.washington.edu> - 2006-07-28 06:15:30
|
> Dmitri A. Sergatskov wrote: > > make[2]: Entering directory `/home/dima/src/gnuplot/tutorial' > > Expected X11 driver: /usr/local/libexec/gnuplot/4.1/gnuplot_x11 > > Exec failed: No such file or directory > > See 'help x11' for more details > > make[2]: *** [eg1.tex] Error 141 > > make[2]: Leaving directory `/home/dima/src/gnuplot/tutorial' > > make[1]: *** [all-recursive] Error 1 > > make[1]: Leaving directory `/home/dima/src/gnuplot' > > make: *** [all] Error 2 On Tuesday 25 July 2006 03:32 pm, Timoth=C3=A9e Lecomte wrote: > Hi Dmitri,=20 > Can you please try the attached patch ? I can understand why the error messages occur, and why your patch makes them go away. But I do not understand why the make failed in Dmitri's case. When I try it here, I get the error messages from the child process that would have become gnuplot_x11, but the main process exits normally and "make" completes successfully. Is there another error lurking here somewhere? =2D-=20 Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: Daniel J S. <dan...@ie...> - 2006-07-28 05:45:49
|
Dmitri A. Sergatskov wrote:
> Today's cvs on Fedora Core 5 (x86_64).
> ./prepare
> CFLAGS="-O3 -m64 -pipe"
> ./configure --with-readline=gnu
> make
> make[2]: Leaving directory `/home/dima/src/gnuplot/demo'
> Making all in tutorial
> make[2]: Entering directory `/home/dima/src/gnuplot/tutorial'
> Expected X11 driver: /usr/local/libexec/gnuplot/4.1/gnuplot_x11
> Exec failed: No such file or directory
> See 'help x11' for more details
> make[2]: *** [eg1.tex] Error 141
> make[2]: Leaving directory `/home/dima/src/gnuplot/tutorial'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/home/dima/src/gnuplot'
> make: *** [all] Error 2
>
> (Of course it worked on the computer that had an older version
> installed in /usr/local ...)
[I think this is one for Hans...]
Right. I suppose developers have had a /usr/local/libexec/gnuplot/4.1/gnuplot_x11 always present. I've replicated the bug. Running as su will install gnuplot_x11 and things will be fine.
So, this error message "Expected X11 driver:" is coming from gnuplot, the x11.trm file. Gnuplot must be run in order to build the files eg1.tex, eg2.tex, etc. Here is the command that fails:
fprintf(stderr,"Expected X11 driver: %s\n",X11_full_command_path);
and this X11_full_command_path is gotten from an environment variable:
/* HBB 20020214: new code to prepend the environment X11_DRIVER_DIR
* to the command name, if it doesn't contain any slashes yet */
if (!strchr(optvec[0],'/')) {
char *dir = getenv("GNUPLOT_DRIVER_DIR");
If GNUPLOT_DRIVER_DIR is not defined, then apparently the default is used which you've discovered contains no executable.
Hans, is the best solution here to simply define GNUPLOT_CRIVER_DIR as a relative path when running this tutorial Makefile?
Really, the gnuplot x11 driver is not needed for the purpose of this tutorial. Perhaps there should be a command line option to indicate that the default window environment driver should not be launched? Or better yet, an option to indicate the default terminal:
gnuplot -term postscript
Dan
|
|
From: <br...@ph...> - 2006-07-28 10:27:18
|
Guys, I suspect we're chasing a red herring. Let me repeat this: Hans-Bernhard Br=F6ker wrote: > gnuplot_x11 isn't even supposed to be started by this run of gnuplo= t.=20 > And it isn't --=20 gnuplot_x11 is *not* actually needed by tutorial/Makefile's invocatio= ns=20 of gnuplot. I know that for several independent reasons: 1) my local working copy is versioned 4.2-rc1, so it looks for=20 /usr/local/libexec/gnuplot/4.2/gnuplot_x11, which never existed at an= y=20 time during this exercise. 2) To be extra sure, I *removed* all installed gnuplots from this cyg= win=20 box, and it still failed to fail. 3) the LaTeX and EPS output files are generated in spite of those mes= sages. We're looking at *warnings* here, not errors. |
|
From: <tim...@en...> - 2006-07-28 18:15:56
|
Hans-Bernhard Br=F6ker wrote: > Guys, I suspect we're chasing a red herring. > > Let me repeat this: > > Hans-Bernhard Br=F6ker wrote: > =20 >> gnuplot_x11 isn't even supposed to be started by this run of gnuplot.=20 >> And it isn't --=20 >> =20 > > gnuplot_x11 is *not* actually needed by tutorial/Makefile's invocations= =20 > of gnuplot. I know that for several independent reasons: > > 1) my local working copy is versioned 4.2-rc1, so it looks for=20 > /usr/local/libexec/gnuplot/4.2/gnuplot_x11, which never existed at any=20 > time during this exercise. > > 2) To be extra sure, I *removed* all installed gnuplots from this cygwi= n=20 > box, and it still failed to fail. > > 3) the LaTeX and EPS output files are generated in spite of those messa= ges. > > We're looking at *warnings* here, not errors. I think I have found what is needed to reproduce the error. I tried with ./configure --with-readline=3Dgnu, and get the "Exec"=20 warning, the 'make' error, and no .tex nor .eps files generated. However, with ./configure (i.e. with the builtin readline), I get the=20 "Exec" warning but the .tex and .eps files _are_ generated. =3D> There is a problem with GNU readline. Timoth=E9e |
|
From: Ethan M. <merritt@u.washington.edu> - 2006-07-28 18:33:03
|
On Friday 28 July 2006 01:15 pm, Timoth=E9e Lecomte wrote: > I tried with ./configure --with-readline=3Dgnu, and get the "Exec" > warning, the 'make' error, and no .tex nor .eps files generated. > However, with ./configure (i.e. with the builtin readline), I get the > "Exec" warning but the .tex and .eps files _are_ generated. > > =3D> There is a problem with GNU readline. More likely a problem with term->waitforinput(). Anyhow, I have fixed the original problem by having .../tutorial/Makefile set GNUTERM to "latex" before running the demo scripts. We can continue to discuss whether it is a mistake to initialize x11 on entry if it is the default terminal. =2D-=20 Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle WA |
|
From: Daniel J S. <dan...@ie...> - 2006-07-30 06:25:03
|
Ethan Merritt wrote: > We can continue to discuss whether it is a mistake to initialize > x11 on entry if it is the default terminal. Well, it sort of is (unless in some initialization file the user specifies that the desired terminal is x11). I've just seen another bug in the SourceForge list: [ 997481 ] [autoconf] name transformation of gnuplot_x11 which is closely related to this issue. We should probably clear this up and get rid of this bug report. I've just tested as the bug reporter instructed. After build is the X11 driver: [gnuplot]# ls /usr/local/libexec/gnuplot/4.1 gnuplot_x11-suffix gnuplot_x11_tempmovedhere [gnuplot]# gnuplot Expected X11 driver: /usr/local/libexec/gnuplot/4.1/gnuplot_x11 Exec failed: No such file or directory See 'help x11' for more details 1) The first thing that strikes me is that I get the instruction "See 'help x11' for more details". However, how do I see the help when I can't get to the program command line? So, this really shouldn't be a critical error in my opinion. Yes, the x11 driver should register an error, but in a graceful way from the command line. 2) As for gnuplot attempting to find gnuplot_x11 at start up. Perhaps this should be delayed to the point of first trying to create a plot. Is that possible? Keep in mind, if the error is more graceful as in (1) then this really isn't a critical issue anymore as gnuplot wouldn't critically fail. There would be the error message and the user could simply change to a different terminal driver. But still, not having the error message until absolutely necessary would be nice. 3) As to the original bug report, so long as someone is looking at this, would the patch I put on SourceForge suffice? If one does something like ./prepare ./configure --program-prefix=PRE --program-suffix=SUF make install The files PREgnuplotSUF and PREgnuplot_x11SUF will be created. In the bug report, Hans states that adding the suffix to gnuplot-x11 isn't necessary. However, I'd argue it is. The person who uses "program-suffix" is someone who might create a special version of the program that has a recent patch or something. If that patch effected gplt_x11.c then it would be nice to have the two different versions of gnuplot_x11 and gnuplot_x11-suffix. E.g., someone wants the most recent official release and one with a great new feature, "gnuplot" and "gnuplotspif". 4) Could the following warnings be removed? checking for CAIRO... Package cairo was not found in the pkg-config search path.Perhaps you should add the directory containing `cairo.pc' to the PKG_CONFIG_PATH environment variable No package 'cairo' found configure: WARNING: Cairo can't be found. The wxWidgets terminal will not be compiled. checking for PANGO... Requested 'pango >= 1.10' but version of Pango is 1.6.0 configure: WARNING: Pango can't be found. The wxWidgets terminal will not be compiled. checking for PANGOCAIRO... Package pangocairo was not found in the pkg-config search path. Perhaps you should add the directory containing `pangocairo.pc' to the PKG_CONFIG_PATH environment variable No package 'pangocairo' found configure: WARNING: Cairo rendering support for Pango can't be found. The wxWidgets terminal will not be compiled. Isn't it the job of the auto-build tools to sort out what should and shouldn't be built? This isn't a valid situation for warnings from my perspective. Dan |
|
From: Daniel J S. <dan...@ie...> - 2006-07-30 07:26:20
|
Daniel J Sebald wrote: > 1) The first thing that strikes me is that I get the instruction > "See 'help x11' for more details". However, how do I see the help >when I can't get to the program command line? So, this really >shouldn't be a critical error in my opinion. Yes, the x11 driver > should register an error, but in a graceful way from the command line. > > 2) As for gnuplot attempting to find gnuplot_x11 at start up. > Perhaps this should be delayed to the point of first trying to create a plot. I put a patch on SourceForge that will remove X11_init() from X11_options(). This solves the above problem. If gnuplot_x11 is missing, the command line behaves as: Terminal type set to 'x11' gnuplot> plot x Expected X11 driver: /usr/local/libexec/gnuplot/4.1/gnuplot_x11 Exec failed: No such file or directory See 'help x11' for more details Note that the exit is apparently re-routed back to the command line at this point in the program. So, after I hit return, then the command line prompt comes back. It isn't the as graceful as it could be, but I think it is good enough for the situation it addresses. What the ramification of removing that X11_init() is I'm not sure. Perhaps Ethan has a better feel for that. There aren't any font characteristics or something that gnuplot_x11 is needed for inside X11_options(), is there? Dan |
|
From: James R. V. Z. <jr...@co...> - 2006-07-30 19:08:02
|
Daniel J Sebald <dan...@ie...> wrote:
> 4) Could the following warnings be removed?
>
> checking for CAIRO... Package cairo was not found in the
> pkg-config search path.
> Perhaps you should add the directory containing `cairo.pc' to the
> PKG_CONFIG_PATH environment variable
> No package 'cairo' found
> configure: WARNING: Cairo can't be found. The wxWidgets terminal
> will not be compiled.
...
>
> Isn't it the job of the auto-build tools to sort out what should
> and shouldn't be built? This isn't a valid situation for warnings
> from my perspective.
I for one appreciate these warnings. If I am interested in the
missing functionality, they tell me what other software I should look
for.
- Jim Van Zandt
|
|
From: Daniel J S. <dan...@ie...> - 2006-07-30 19:57:02
|
James R. Van Zandt wrote: > Daniel J Sebald <dan...@ie...> wrote: > > >> 4) Could the following warnings be removed? >> >> checking for CAIRO... Package cairo was not found in the >> pkg-config search path. >> Perhaps you should add the directory containing `cairo.pc' to the >> PKG_CONFIG_PATH environment variable >> No package 'cairo' found >> configure: WARNING: Cairo can't be found. The wxWidgets terminal >> will not be compiled. > > ... > >> Isn't it the job of the auto-build tools to sort out what should >> and shouldn't be built? This isn't a valid situation for warnings >> from my perspective. > > > I for one appreciate these warnings. If I am interested in the > missing functionality, they tell me what other software I should look > for. Yes, but the key word there being "if". I mean, why can't this: checking for CAIRO... Package cairo was not found in the pkg-config search path.Perhaps you should add the directory containing `cairo.pc' to the PKG_CONFIG_PATH environment variable No package 'cairo' found configure: WARNING: Cairo can't be found. The wxWidgets terminal will not be compiled. be summarized as: checking for CAIRO... no As with the several other cases where "no" comes up in the ./configure operation, logic tells me that configure could not find the package and therefore it will not be included in the compilation. Why does there need to be a WARNING to tell me that? The only real bit of info in the above message is "Perhaps you should add the directory containing `cairo.pc' to the PKG_CONFIG_PATH environment variable" and even that is wordy. And, once that is stated it becomes redundant information when it is displayed several more times later. And this one: checking for PANGO... Requested 'pango >= 1.10' but version of Pango is 1.6.0 could be: checking for PANGO... found 1.6.0, require >= 1.10 Most people understand the ramification of that. We don't then need to know: configure: WARNING: Pango can't be found. The wxWidgets terminal will not be compiled. which in fact seems like a conflicting report to me. Pango WAS found, it just isn't a recent enough version. Perhaps there should be a verbose mode for configure. Dan |
|
From: <tim...@en...> - 2006-07-30 20:13:53
|
Daniel J Sebald wrote: > James R. Van Zandt wrote: > =20 >> >> I for one appreciate these warnings. If I am interested in the >> missing functionality, they tell me what other software I should look >> for.=20 >> =20 > > Yes, but the key word there being "if". I mean, why can't this: > > checking for CAIRO... Package cairo was not found in the pkg-config sea= rch path.Perhaps you should add the directory containing `cairo.pc' > to the PKG_CONFIG_PATH environment variable > No package 'cairo' found > =20 The above messages are the defaults provided by pkg-config. If we change=20 them, we lose the ability to exactly know why it doesn't find the=20 package. See your own example below about the versions required. > configure: WARNING: Cairo can't be found. The wxWidgets terminal will n= ot be compiled. > =20 I wrote this one, and I am willing to improve the message if you think=20 we can do better. For example, I can replace "WARNING" by "NOTE". > The only real bit of info in the above message is "Perhaps you should a= dd the directory containing `cairo.pc' > to the PKG_CONFIG_PATH environment variable" and even that is wordy. A= nd, once that is stated it becomes redundant information when it is displ= ayed several more times later. > =20 It is not redundant as different packages are concerned. > And this one: > > checking for PANGO... Requested 'pango >=3D 1.10' but version of Pango = is 1.6.0 > > could be: > > checking for PANGO... found 1.6.0, require >=3D 1.10 > =20 To me, that's just the same. > configure: WARNING: Pango can't be found. The wxWidgets terminal will n= ot be compiled. > > which in fact seems like a conflicting report to me. Pango WAS found, = it just isn't a recent enough version. > =20 I can reword that into "No valid Pango package was found. The wxWidgets=20 terminal will not be compiled." if you prefer. Best regards, TImoth=E9e |
|
From: Ethan A M. <merritt@u.washington.edu> - 2006-07-30 20:14:22
|
On Sunday 30 July 2006 02:54 pm, Timoth=E9e Lecomte wrote: > Daniel, would it satisfy you if I replace the "WARNING" by "NOTE" ? Let them stay as they are. After 200 lines of semi-intelligible output from the configure script we have no control over, why quibble about warnings that actually contain useful information? =2D-=20 Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: Daniel J S. <dan...@ie...> - 2006-07-30 20:33:06
|
> Let them stay as they are. OK. > After 200 lines of semi-intelligible output from the > configure script we have no control over, why quibble about > warnings that actually contain useful information? Humid weather... err! Dan |
|
From: Daniel J S. <dan...@ie...> - 2006-07-30 20:28:37
|
Timoth=E9e Lecomte wrote: >> checking for CAIRO... Package cairo was not found in the pkg-config=20 >> search path.Perhaps you should add the directory containing `cairo.pc' >> to the PKG_CONFIG_PATH environment variable >> No package 'cairo' found >> =20 >=20 >=20 > The above messages are the defaults provided by pkg-config. Oh, sorry. Why is configure so terse in one instance, and then here gets= so wordy with stuff like "Perhaps you should"? >> configure: WARNING: Cairo can't be found. The wxWidgets terminal will=20 >> not be compiled. >> =20 >=20 >=20 > I wrote this one, and I am willing to improve the message if you think=20 > we can do better. For example, I can replace "WARNING" by "NOTE". >=20 >> The only real bit of info in the above message is "Perhaps you should=20 >> add the directory containing `cairo.pc' >> to the PKG_CONFIG_PATH environment variable" and even that is wordy. =20 >> And, once that is stated it becomes redundant information when it is=20 >> displayed several more times later. >> =20 >=20 > It is not redundant as different packages are concerned. Same bloated sentence with one word different. High entropy, low informa= tion content. >=20 >> And this one: >> >> checking for PANGO... Requested 'pango >=3D 1.10' but version of Pango= =20 >> is 1.6.0 >> >> could be: >> >> checking for PANGO... found 1.6.0, require >=3D 1.10 >> =20 >=20 >=20 > To me, that's just the same. Right, but it is shorter and fits on one line rather than wrapping at 80 = chars. (Is this another "configure issued" default warning?) > I can reword that into "No valid Pango package was found. The wxWidgets= =20 > terminal will not be compiled." if you prefer. I'm suggesting to be more brief and include info at appropriate locations= . Having too much extraneous info can sometimes be just as big a problem= as not enough info. I just think that at the point where configure checks for packages and ca= n't find them it isn't necessary to say what the ramification of that is = just yet. I'd think at the bottom in the list of what is included might = be better. Dan |
|
From: <tim...@en...> - 2006-07-30 20:42:55
|
Daniel J Sebald wrote: > Timoth=E9e Lecomte wrote: > >>> checking for CAIRO... Package cairo was not found in the pkg-config=20 >>> search path.Perhaps you should add the directory containing `cairo.pc= ' >>> to the PKG_CONFIG_PATH environment variable >>> No package 'cairo' found >>> =20 >> >> >> The above messages are the defaults provided by pkg-config. > > Oh, sorry. Why is configure so terse in one instance, and then here=20 > gets so wordy with stuff like "Perhaps you should"? Hey, that's how humans work, sometimes wordy, sometimes terse ;-) (it=20 reminds me of "Cathedrals, Bazaars and the Town Council" from Alan Cox). > >> >>> And this one: >>> >>> checking for PANGO... Requested 'pango >=3D 1.10' but version of Pang= o=20 >>> is 1.6.0 >>> >>> could be: >>> >>> checking for PANGO... found 1.6.0, require >=3D 1.10 >>> =20 >> >> >> To me, that's just the same. > > Right, but it is shorter and fits on one line rather than wrapping at=20 > 80 chars. (Is this another "configure issued" default warning?) Yes, another pkg-config defaults. > I'd think at the bottom in the list of what is included might be better= .=20 Let's add to the post-4.2 list : "rework final report from ./configure,=20 with both the _brief_ list of compiled-in features and the _brief_ list=20 of not-compiled in features, with the corresponding requirements". Best regards, Timoth=E9e |
|
From: <tim...@en...> - 2006-07-30 19:54:59
|
James R. Van Zandt wrote: > Daniel J Sebald <dan...@ie...> wrote: > > =20 >> 4) Could the following warnings be removed? >> >> checking for CAIRO... Package cairo was not found in the >> pkg-config search path. >> Perhaps you should add the directory containing `cairo.pc' to the >> PKG_CONFIG_PATH environment variable >> No package 'cairo' found >> configure: WARNING: Cairo can't be found. The wxWidgets terminal >> will not be compiled. >> =20 > ... > =20 >> Isn't it the job of the auto-build tools to sort out what should >> and shouldn't be built? This isn't a valid situation for warnings >> from my perspective. >> =20 > > I for one appreciate these warnings. If I am interested in the > missing functionality, they tell me what other software I should look > for.=20 > > - Jim Van Zandt > =20 Daniel, would it satisfy you if I replace the "WARNING" by "NOTE" ? Best regards, TImoth=E9e |
|
From: Daniel J S. <dan...@ie...> - 2006-07-30 20:14:34
|
Timoth=E9e Lecomte wrote: > James R. Van Zandt wrote: >=20 >> Daniel J Sebald <dan...@ie...> wrote: >> >> =20 >> >>> 4) Could the following warnings be removed? >>> >>> checking for CAIRO... Package cairo was not found in the >>> pkg-config search path. >>> Perhaps you should add the directory containing `cairo.pc' to the >>> PKG_CONFIG_PATH environment variable >>> No package 'cairo' found >>> configure: WARNING: Cairo can't be found. The wxWidgets terminal >>> will not be compiled. >>> =20 >> >> ... >> =20 >> >>> Isn't it the job of the auto-build tools to sort out what should >>> and shouldn't be built? This isn't a valid situation for warnings >>> from my perspective. >>> =20 >> >> >> I for one appreciate these warnings. If I am interested in the >> missing functionality, they tell me what other software I should look >> for. >> - Jim Van Zandt >> =20 >=20 > Daniel, would it satisfy you if I replace the "WARNING" by "NOTE" ? Not really. In my opinion, be more terse. Here there are three warnings= : configure: WARNING: Pango can't be found. The wxWidgets terminal will not= be compiled. configure: WARNING: Cairo can't be found. The wxWidgets terminal will not= be compiled. configure: WARNING: Cairo rendering support for Pango can't be found. The= wxWidgets terminal will not be compiled. stating wxWidgets terminal will not be included. Too wordy and redundant. Ethan, what kind of warning messages are given when JPEG, PNG, etc. aren'= t available? Can this be summarized at the bottom of ./configure along w= ith all the other items listed? E.g., Do not build wxWidgets (requires Cairo, Pango or CairoPango) Dan |
