Menu
▾
▴
gnuplot-beta
|
From: <tim...@en...> - 2006-04-29 07:25:11
|
Dear gnuplot developpers, After 11 months of development, the wxWidgets has landed to the CVS ! (I hope I did not make any mistake by the way) I really would like to thank you, Hans-Bernhard, Ethan, Bastian, Petr, Daniel, Ga=EBl for your help and your comments. Let me explain a little about this work. I think I fully fulfilled my initial goal : to contribute to an open-source project, to learn more about programming, and to make something to improve gnuplot, which I had used several times and appreciated, as a graduating physics student (I now use it every day for = a research internship in solid-state physics). From the pure wxWidgets terminal that it was at first, the concept evolve= d to a separation between the gui implemented in wxWidgets and the actual plot rendering with cairo and pango. Meanwhile, my aim to work on interactivity moved to rendering quality. I learned a lot about the problems of graphics rendering. Using antialiasing intelligently is not that straightforward, but hopefully the terminal implements it in a smart enough way. What to expect from this work in the future ? First, the terminal is highly cross-platform. To add a new supported platform, you "just" have to figure out a few thin= gs : - does wxWidgets on this platform require additional initialization calls (probably not)? - do I need to process the gui messages in a new loop (probably yes)? - do wxWidgets on this platform support all the currently implemented features (almost surely yes)? - how to compile it ? With these questions in mind, you can walk along the code in wxt_gui.cpp and see whether you are in the wxGTK (ie wxWidgets built on top of gtk) o= r wxMSW (ie wxWidgets on top of Windows) case. In addition to that, it is possible to add cairo hooks for direct rendering to screen. It is currently implemented for Windows but not for Unix, so that the wxWidgets terminal will be faster on Windows than on Unix ! The code to activate it for Unix is there but not enabled because current X servers do mostly fall back to software rendering, so it tends to be slower than the all-software (and all cross-platform) rendering. It means that it should be quite easy to make this terminal work for OS/2= , and Mac. Then, cairo is still a very young library. It is already working quite well : on a surface plot with pm3d, the rendering needs twice as much tim= e as the X11 terminal, but the plot is completely antialiased ! Nevertheless cairo is promised to a bright future. The next version (cair= o 1.2) which is supposed to be ready in a few weeks, will add full support for postscript and PDF output, and probably SVG. The following version to be out at the end of this year, will be focused on performance. Currently= , it is worth noticing that cairo has received few attention regarding optimization. Many algorithms (tesselator...) are said to be candidates for a major speedup. cairo will be used in firefox 2 as the rendering library on all platforms. It means that we will profit from a library use= d very broadly (gtk+ and firefox). No doubt that the wxWidgets terminal wil= l be faster in the next months. Thank you again, and have fun with gnuplot ! Regards, Timoth=E9e |
|
From: Ethan A M. <merritt@u.washington.edu> - 2006-04-29 16:52:31
|
On Saturday 29 April 2006 12:25 am, Timoth=E9e Lecomte wrote: > After 11 months of development, the wxWidgets has landed to the CVS !=20 Congrats! There are still some points that I do not understand about the terminal, even though I've been using it for a while now. Could you provide some additional information on - where does the terminal find its fonts? If I want to make a new font available to it, where do I put it or what do I need to change in the system configuration? - How do I disable the 'q' and 'spacebar' hotkeys. I know we've been discussing changing this everywhere, but how do I do it right now? - I do not understand what the logic is for resizing the plot=20 drawn in a resized window. Unlike most (all?) other terminals, the plot is not always redrawn so that it fills the window. An explicit "replot" command always causes the plot to be redrawn so that it fills the window; why does the dynamic re-sizing behave differently? - Also when the plot window is resized, sometimes the font size stays the same, sometimes it scales smoothly, and sometimes it jumps in increments. =20 - (programmers question): If I want to add itenms to the configuration menu widget, what is required? For instance, could one add a font browser there? =2D-=20 Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: <tim...@en...> - 2006-04-29 21:25:49
|
> On Saturday 29 April 2006 12:25 am, Timoth=E9e Lecomte wrote: >> After 11 months of development, the wxWidgets has landed to the CVS ! > > Congrats! > > There are still some points that I do not understand about the terminal= , > even though I've been using it for a while now. > Could you provide some additional information on > > - where does the terminal find its fonts? If I want to make a > new font available to it, where do I put it or what do I need > to change in the system configuration? This is not explicitely detailed in the pango documentation, but it seems reasonable to assume the following : On Unix, pango can use any fonts that are know to FontConfig. Here is wha= t the GIMP documentation says about adding fonts to FontConfig: "As soon as Fontconfig is properly setup, adding fonts is just a matter o= f placing them into a directory that is searched by Fontconfig. Have a look at /etc/fonts/fonts.conf (and perhaps /etc/fonts/local.conf) to find out what directories are searched. After copying the fonts there, you should run fc-cache to regenerate the fonts cache. Fonts added this way will be available to all applications using Fontconfig." For example, on my system, /etc/fonts/fonts.conf says that it will look i= nto: /usr/share/fonts /usr/X11R6/lib/X11/fonts/TTF /usr/X11R6/lib/X11/fonts/Type1 /usr/X11R6/lib/X11//fonts/misc /usr/X11R6/lib/X11/fonts/local /usr/lib/X11/fonts/TTF /usr/lib/X11/fonts/Type1 /usr/lib/X11/fonts/misc /usr/lib/X11/fonts/local ~/.fonts The last line allows you to install a font in your home directory, so tha= t you don't need administrator rights to add a font. FontConfig will also look for user configuration in ~/.fonts.conf This file also sets some aliases. For example, my configuration file states that if I choose "serif" as a font, it will use either Bitstream Vera Serif, Times New Roman, Luxi Serif, Times, etc. Pango will use the first one that is able to represent all the characters of the string it has to render. Note that I have not done anything to configure this. It is usually done by the distribution, and it is likely that you desktop environment provides a configuration utility to add fonts to FontConfig (KDE and Gnom= e do). On Windows, Pango will use the native Windows font system, so it should b= e customizable via the fonts control panel. > - How do I disable the 'q' and 'spacebar' hotkeys. > I know we've been discussing changing this everywhere, > but how do I do it right now? Currently you can't disable it. I'm sorry ! By the way, if I implement something to optionally disable it, this 'spacebar'/'q' topic may vanish again. Let's come up with a global solution that everybody agrees on. Then I would be glad to implement it. > - I do not understand what the logic is for resizing the plot > drawn in a resized window. Unlike most (all?) other terminals, > the plot is not always redrawn so that it fills the window. > An explicit "replot" command always causes the plot to be redrawn > so that it fills the window; why does the dynamic re-sizing behave > differently? It will resize the plot to fit in the window, but will keep the aspect ratio (width/height) constant, so that if you just increase the window width, nothing happens. This behaviour can be discussed, and if needed, options can be added to the configuration dialog. > - Also when the plot window is resized, sometimes the font size > stays the same, sometimes it scales smoothly, and sometimes > it jumps in increments. I think it is related to the font antialiasing methods that are used by pango. To make a font look nice on the screen, you have to make it fit to the pixel grid. Here are the relevant parts of the cairo font documentation : "Hinting is the process of fitting font outlines to the pixel grid in order to improve the appearance of the result. Since hinting outlines involves distorting them, it also reduces the faithfulness to the origina= l outline shapes." A side effect is that this fitting depends on the font size, so that the font won't scale absolutely linearly with the window size. > - (programmers question): If I want to add itenms to the configuration > menu widget, what is required? For instance, could one add a font > browser there? The code for this widget lives in the wxtConfigDialog class. A dialog like this is based on several controls (a checkbox, a slider, etc.) embedded into "sizers", which will take care of their position in the window (should the control be aligned on the left ? should it expand with the window ? does it have a border around it ? etc.). For example, you can easily add a checkbox for "ctrlq", which would behav= e as the checkbox for "raise" or "persist". When OK or APPLY is clicked, th= e value will be written in the wxConfig object, which represents a entry in the registry under Windows, or a file ~/.gnuplot-wxt under Unix. This value can then be used where appropriate. I would be glad to give more details about it, but I would end up rewriting the wxWidgets documentation ! (http://www.wxwidgets.org/manuals= ) As far as a font browser is concerned, wxWidgets provides one : http://www.wxwidgets.org/manuals/2.6.3/wx_commondialogsoverview.html#wxfo= ntdialogoverview It will list fonts and present a sample of the selected one. I hope this helps. Best regards, Timoth=E9e |
|
From: Ethan A M. <merritt@u.washington.edu> - 2006-04-29 22:29:57
|
On Saturday 29 April 2006 02:25 pm, you wrote:
>
> "As soon as Fontconfig is properly setup, adding fonts is just a matter of
> placing them into a directory that is searched by Fontconfig. Have a look
> at /etc/fonts/fonts.conf (and perhaps /etc/fonts/local.conf) to find out
> what directories are searched.
Aha. Thanks!
I did not know about that mechanism at all, and have not
been using it. Adding that file makes a lot of difference :-) :-)
My X11 setup uses a similar mechanism, but does it through
/etc/X11/fs/config rather than /etc/fonts/fonts.conf
With that file in place, I can now use all the fonts that I
couldn't get before in wxt. Including "Wingdings", which I thought you
had said before was not working. However, while playing around with this
I triggered the following:
%%%%%%%%%%%%%%%%%%%%% begin session log %%%%%%%%%%%%%%%%%%%%%%%%%%%%
lascaux [515] ./gnuplot
G N U P L O T
Version 4.1 patchlevel 0
last modified April 2006
System: Linux 2.6.12-12mdksmp
Copyright (C) 1986 - 1993, 1998, 2004
Thomas Williams, Colin Kelley and many others
Type `help` to access the on-line reference manual.
The gnuplot FAQ is available from
http://www.gnuplot.info/faq/
Send comments and requests for help to
<gnu...@li...>
Send bugs, suggestions and mods to
<gnu...@li...>
Terminal type set to 'wxt'
gnuplot> set term wxt font 'vivaldi,20'
Terminal type set to 'wxt'
Options are '0 font "vivaldi,20"'
gnuplot> plot sin(x)/x
gnuplot>
gnuplot> set term wxt font 'wingdings,20'
Terminal type set to 'wxt'
*** glibc detected *** free(): invalid next size (fast): 0x083df148 ***
Abort
%%%%%%%%%%%%%%%%%%%%% end session log %%%%%%%%%%%%%%%%%%%%%%%%%%%%
Any idea what that's all about?
It is not the use of wingdings per se, because the font works
fine if I select it first rather than second.
Here is a minimal crashme.dem example:
# Demonstrate bug in wxt
set term wxt font "arial"
plot sin(x)
# crashes on next line, but only if a font size is given
set term wxt font "wingdings,20"
replot
And here is a trace from gdb:
*** glibc detected *** free(): invalid next size (fast): 0xb5c00510 ***
Program received signal SIGABRT, Aborted.
[Switching to Thread -1229027648 (LWP 11253)]
0xffffe410 in __kernel_vsyscall ()
(gdb) where
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb6e43ef1 in raise () from /lib/tls/libc.so.6
#2 0xb6e4583b in abort () from /lib/tls/libc.so.6
#3 0xb6e79ff5 in __fsetlocking () from /lib/tls/libc.so.6
#4 0xb6e80587 in malloc_usable_size () from /lib/tls/libc.so.6
#5 0xb6e80a02 in free () from /lib/tls/libc.so.6
#6 0x08143215 in wxt_options () at ../term/wxt.trm:219
#7 0x080e4976 in set_terminal () at set.c:3645
#8 0x080db773 in set_command () at set.c:436
#9 0x08062221 in command () at command.c:530
#10 0x08061d2b in do_line () at command.c:382
#11 0x08061ba0 in com_line () at command.c:333
#12 0x080c1c56 in main (argc=1, argv=0xbff13294) at plot.c:638
--
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742
|
|
From: <tim...@en...> - 2006-04-30 07:44:20
|
> On Saturday 29 April 2006 02:25 pm, you wrote:
>>
>> "As soon as Fontconfig is properly setup, adding fonts is just a matte=
r
>> of
>> placing them into a directory that is searched by Fontconfig. Have a
>> look
>> at /etc/fonts/fonts.conf (and perhaps /etc/fonts/local.conf) to find o=
ut
>> what directories are searched.
>
> Aha. Thanks!
> I did not know about that mechanism at all, and have not
> been using it. Adding that file makes a lot of difference :-) :-)
> My X11 setup uses a similar mechanism, but does it through
> /etc/X11/fs/config rather than /etc/fonts/fonts.conf
>
> With that file in place, I can now use all the fonts that I
> couldn't get before in wxt. Including "Wingdings", which I thought you
> had said before was not working.
Hmmm. Interesting. Indeed, Wingdings works for me too. You made me give
another look at the "Symbol font problem", and I finally figure out the
following :
There are two types of Symbol fonts : the Adobe one, and the Microsoft
one. The Microsoft one is likely to use a different mapping than the Adob=
e
one, and the Adobe encoding is the "official". I have a Microsoft symbol
font installed (symbol.ttf in one of the fonts paths). I also had an Adob=
e
one brought by Acrobat Reader, but not in the fontconfig path. Finally I
had the Opensymbol font, brought by Openoffice (and available on several
distributions as a separate package), but again not in the fontconfig
path.
I added the two of them to the fontconfig package, runned 'fc-cache' and
they immediately appeared in all my kde apps ! Fontconfig is great !
However, they still appear with the utf-8 encoding, that is to say that
enhancedtext.dem still won't work without the function that translates th=
e
"Symbol encoding" to the utf-8 encoding.
That means that the system knows that the Symbol encoding is special, and
handle the case separately. After looking a little more, I found the
following file :
/usr/X11R6/lib/X11/fonts/encoding/adobe-symbol.enc.gz
which contains precisely the map from the Symbol characters to Unicode !
That's why the system understands this font as a normal font, after
applying this encoding translation.
So currently the path is the following :
input in Symbol encoding -> translation from Symbol to utf-8 by wxt ->
translation from utf-8 to the custom Symbol encoding by pango/X11 ->
proper rendering in the Symbol font
My layer ("translation to utf-8 by the wxWidgets terminal") is useful to
maintain compatibility with enhancedtext.dem, but will not work if the
user already enters its characters in utf-8 and chooses the Symbol font...
In this case the layer should not be used, and the characters should be
sent directly to pango.
Ouch ! Still have to figure out how to satisfy all cases...
Timoth=E9e
|
|
From:
<br...@ph...> - 2006-04-30 21:53:45
|
Timothée Lecomte wrote: > After 11 months of development, the wxWidgets has landed to the CVS ! (Belated) congratulations from me, too. To explain why it took me so long: I tried to build this thing before commenting any further. On Win32, just to make it bit more interesing. Gosh --- I haven't had to download and install so many other packages to compile a single one since the days a Linux distro was something that fit on two or three dozen floppies, and running X11 on it was considered an extravagant option. Let's see: so I had to get wxWidgets, obviously. Getting that to compile was, ... tricky. And its "make install" doesn't work --- puts the DLLs in $(prefix)/lib place where wgnuplot.exe doesn't find them. Windows tradition is to put DLLs in a the same place as the executables, since they'll be searched along the PATH. On top of that then I needed to add to my MSYS/MinGW installation: pkg-config, fontconfig, glib, cairo, pango, libpng (had it already, but not "libpng13", and no pkg-config file), gettext, libiconv. I eventually gave up on building cairo and pango from source. Now that I forced pkg-config to work, maybe I'll revisit cairo. And that's before I even begin investigating the possibility of using my now favourite Windows C/C++ compiler, OpenWatcom, to do this job. I'm not even sure how to compile wxWidgets with that, yet. I may have to dogde that and use MinGW-compiled DLLs with an OW-compiled wgnuplot. So, lots of new things to discover. |
|
From: <tim...@en...> - 2006-05-01 00:28:43
|
> Timoth=E9e Lecomte wrote: >> After 11 months of development, the wxWidgets has landed to the CVS ! > > (Belated) congratulations from me, too. > > To explain why it took me so long: I tried to build this thing before > commenting any further. On Win32, just to make it bit more interesing. > Gosh --- I haven't had to download and install so many other packages > to compile a single one since the days a Linux distro was something tha= t > fit on two or three dozen floppies, and running X11 on it was considere= d > an extravagant option. > > Let's see: so I had to get wxWidgets, obviously. Getting that to > compile was, ... tricky. And its "make install" doesn't work --- puts > the DLLs in $(prefix)/lib place where wgnuplot.exe doesn't find them. > Windows tradition is to put DLLs in a the same place as the executables= , > since they'll be searched along the PATH. Two remarks : wxWidgets lacks precompiled libraries. It is said to be the policy of its developpers not to provide any binaries, because that would be unrighteou= s to do that for one platform (likely Windows) but not others. You seem to have compiled wxWidgets as shared libraries. You can also compile it statically in gnuplot. That's what I have done for all the snapshots that I provided on sourceforge. > On top of that then I needed to add to my MSYS/MinGW installation: > pkg-config, fontconfig, glib, cairo, pango, libpng (had it already, but > not "libpng13", and no pkg-config file), gettext, libiconv. I > eventually gave up on building cairo and pango from source. Now that I > forced pkg-config to work, maybe I'll revisit cairo. Fortunately, we have precompiled binaries for all of these on Windows ! The following page helped me to find them : http://www.freeciv.org/index.php/Install-Windows By the way, the only problem I had with pkg-config was to set up the path correctly. Is it also what you mean by forcing pkg-config to work ? > And that's before I even begin investigating the possibility of using m= y > now favourite Windows C/C++ compiler, OpenWatcom, to do this job. I'm > not even sure how to compile wxWidgets with that, yet. I may have to > dogde that and use MinGW-compiled DLLs with an OW-compiled wgnuplot. On the wxWidgets wiki, OpenWatcom is reported to work. > So, lots of new things to discover. I guess it is the price to pay to use these great toys. I just hope it is not too expensive. Timoth=E9e |
|
From:
<br...@ph...> - 2006-05-01 09:39:22
|
Timothée Lecomte wrote: > You seem to have compiled wxWidgets as shared libraries. You can also > compile it statically in gnuplot. I'm aware of that. But I really don't think a library of this size is suitable for static linking. It's simply too huge for that. [cairo, pango & friends...] > Fortunately, we have precompiled binaries for all of these on Windows ! Yes. But what kind of a developer uses prebuilt binaries (and outdated ones, at that), where source is available? > By the way, the only problem I had with pkg-config was to set up the path > correctly. Is it also what you mean by forcing pkg-config to work ? pkg-config is actually quite clever. But the main problem was that some packages I wanted to build insisted on having a "libpng13" --- but the only package I found that actually provided a pkg-config entry under that name appears not to be a native Win32 (--> MinGW32) version. And then of course there's that chicken-and-egg problem between pkg-config and glib... > On the wxWidgets wiki, OpenWatcom is reported to work. Yes --- I discovered the relevant files in the meantime. But it appears to be only a limited part of the overall functionality. Anyway, the true challenge for OpenWatcom will be to build or at least use all that Cairo/Pango stuff. |
|
From: Ethan A M. <merritt@u.washington.edu> - 2006-04-30 22:56:04
|
Configuration fails if wxWidgets is disabled: lascaux [27] ./configure --disable-wxwidgets checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes [...snip...] checking for pdflib.h... yes checking for PDF_begin_pattern in -lpdf... yes checking for PDF_setdashpattern in -lpdf... yes checking for PDF_begin_document in -lpdf... yes checking for multi-byte support in x11... checking for XmbDrawString in -lX11... yes configure: error: conditional "am__fastdepCXX" was never defined. Usually this means the macro was only invoked conditionally. lascaux [28] -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: <tim...@en...> - 2006-05-01 00:35:56
|
> Configuration fails if wxWidgets is disabled: > > lascaux [27] ./configure --disable-wxwidgets > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > [...snip...] > checking for pdflib.h... yes > checking for PDF_begin_pattern in -lpdf... yes > checking for PDF_setdashpattern in -lpdf... yes > checking for PDF_begin_document in -lpdf... yes > checking for multi-byte support in x11... checking for XmbDrawString in > -lX11... yes > configure: error: conditional "am__fastdepCXX" was never defined. > Usually this means the macro was only invoked conditionally. > lascaux [28] The error is pretty explicit. The problem is that I put the following checks in 'if' block : AC_PROG_CXX AC_PROG_CXXCPP I did that because C++ is not needed if the wxWidgets terminal is not compiled. But I have not found any information about such a case on the web. Obviously this doesn't work, so I will have to put them unconditionnally... at the risk of breaking a platform where there's no C++ compiler. Is it acceptable ? Timoth=E9e |
|
From: <tim...@en...> - 2006-05-02 00:14:34
|
>> Configuration fails if wxWidgets is disabled: >> >> lascaux [27] ./configure --disable-wxwidgets >> checking for a BSD-compatible install... /usr/bin/install -c >> checking whether build environment is sane... yes >> checking for gawk... gawk >> checking whether make sets $(MAKE)... yes >> [...snip...] >> checking for pdflib.h... yes >> checking for PDF_begin_pattern in -lpdf... yes >> checking for PDF_setdashpattern in -lpdf... yes >> checking for PDF_begin_document in -lpdf... yes >> checking for multi-byte support in x11... checking for XmbDrawString i= n >> -lX11... yes >> configure: error: conditional "am__fastdepCXX" was never defined. >> Usually this means the macro was only invoked conditionally. >> lascaux [28] > > The error is pretty explicit. The problem is that I put the following > checks in 'if' block : > > AC_PROG_CXX > AC_PROG_CXXCPP > > I did that because C++ is not needed if the wxWidgets terminal is not > compiled. But I have not found any information about such a case on the > web. > Obviously this doesn't work, so I will have to put them > unconditionnally... at the risk of breaking a platform where there's no > C++ compiler. Is it acceptable ? I have been in big trouble ! The autotools are definitely not designed to make a language optional. As reported above, the checks must be done unconditionally or Autoconf won't work. If I put the two checks unconditionally, and execute the resulting 'configure' on a system without any C++ compiler, the script itself will succeed, and I can even disable the wxWidgets terminal, but it will fail at compile time, because the autotools still think that the project contains some C++ files, and tries to link with g++ by default, even when it can't find it ! So this would oblige to have a C++ compiler to build gnuplot, even withou= t the wxWidgets terminal. I respond to my question above : this is obviousl= y not acceptable. I have finally found a workaround : if the C++ compiler is really absent (that can be tested easily), set CXX to $CC, so that automake will finall= y use $CC to do the link. I have tested it, and it seems to work as expected. (but I am not really happy with that, and it made me wonder once again if I should throw wxWidgets in favor of gtk+, which is written in C...) Timoth=E9e |
|
From: Lars H. <lhe...@us...> - 2006-05-18 10:16:33
|
Timoth=E9e Lecomte writes:
> Dear gnuplot developpers,
>=20
> After 11 months of development, the wxWidgets has landed to the CVS ! (=
I
> hope I did not make any mistake by the way)
=20
Timoth=E9e,
I'm trying to repair the build system after this commit. There are two
issues:
| dnl Check for object files creation, needed to build these object files=
in subdirs
| AM_PROG_CC_C_O
This is not what AM_PROG_CC_C_O does. It is a wrapper for AC_PROG_CC_C_O=
:
| If the C compiler does not accept the `-c' and `-o' options
| simultaneously, define `NO_MINUS_C_MINUS_O'. This macro actually
| tests both the compiler found by `AC_PROG_CC', and, if different,
| the first `cc' in the path. The test fails if one fails. This
| macro was created for GNU Make to choose the default C compilation
| rule.
It's not needed. Can I remove it?
Number two: if no wxWidgets are installed, the result for $WX_CONFIG is =
"no",
and configure then tries to run the command "no". I have changed the log=
ic.
if test $WX_CONFIG
...
fi
if expr 2.3.3 \> `${WX_CONFIG} --version`
fi
to
if test $WX_CONFIG
...
else
if expr 2.3.3 \> `${WX_CONFIG} --version`
fi
fi
Ok?
|
|
From: <tim...@en...> - 2006-05-18 16:55:19
|
> Timoth=E9e Lecomte writes:
>> Dear gnuplot developpers,
>>
>> After 11 months of development, the wxWidgets has landed to the CVS ! =
(I
>> hope I did not make any mistake by the way)
>
> Timoth=E9e,
>
> I'm trying to repair the build system after this commit.
Thank you for paying attention to this.
> There are two issues:
>
> | dnl Check for object files creation, needed to build these object fil=
es
> in subdirs
> | AM_PROG_CC_C_O
>
> This is not what AM_PROG_CC_C_O does. It is a wrapper for AC_PROG_CC_C=
_O:
>
> | If the C compiler does not accept the `-c' and `-o' options
> | simultaneously, define `NO_MINUS_C_MINUS_O'. This macro actually
> | tests both the compiler found by `AC_PROG_CC', and, if different,
> | the first `cc' in the path. The test fails if one fails. This
> | macro was created for GNU Make to choose the default C compilatio=
n
> | rule.
>
> It's not needed. Can I remove it?
Interesting remark. In fact, I can see two alternatives :
* I introduced the automake option 'subdir-objects', so that wxt_gui.o fo=
r
example will be put in src/wxterminal/wxt_gui.o instead of src/wxt_gui.o.
Even if it is not specified clearly in the documentation, with
'subdir-objects', we need this AM_PROG_CC_C_O.
If I remove it on my machine (autoconf 2.59, automake 1.9.6), ./prepare
(or autonconf) fails with the following message :
src/Makefile.am: C objects in subdir but `AM_PROG_CC_C_O' not in
`configure.in'
However, the current code is probably wrong as AM_PROG_CC_C_O should be
checked unconditionnally, since 'subdir-objects' is used unconditionnally.
* There's another option : we can remove both 'subdir-objects' in
src/Makefile.am and AM_PROG_CC_C_O in configure.in
Then, wxt_gui.o and gp_cairo.o will be put in src/ instead of
src/wxterminal/, but I can definitely live with that.
So, what's your preference ?
> Number two: if no wxWidgets are installed, the result for $WX_CONFIG i=
s
> "no",
> and configure then tries to run the command "no". I have changed the
> logic.
>
> if test $WX_CONFIG
> ...
> fi
> if expr 2.3.3 \> `${WX_CONFIG} --version`
> fi
>
> to
>
> if test $WX_CONFIG
> ...
> else
> if expr 2.3.3 \> `${WX_CONFIG} --version`
> fi
> fi
>
> Ok?
Yes, you are right. Thanks for pointing this out !
Timoth=E9e
|
|
From:
<br...@ph...> - 2006-05-18 17:14:04
|
Timothée Lecomte wrote: > * There's another option : we can remove both 'subdir-objects' in > src/Makefile.am and AM_PROG_CC_C_O in configure.in > Then, wxt_gui.o and gp_cairo.o will be put in src/ instead of > src/wxterminal/, but I can definitely live with that. > > So, what's your preference ? The above. |
|
From: <tim...@en...> - 2006-05-18 17:26:48
|
> Timoth=E9e Lecomte wrote: > >> * There's another option : we can remove both 'subdir-objects' in >> src/Makefile.am and AM_PROG_CC_C_O in configure.in >> Then, wxt_gui.o and gp_cairo.o will be put in src/ instead of >> src/wxterminal/, but I can definitely live with that. >> >> So, what's your preference ? > > The above. Ok, I agree. I will make this change soon, unless Lars does it before me. Timoth=E9e |
|
From: Lars H. <lhe...@us...> - 2006-05-18 17:38:21
|
Timoth?e Lecomte writes: > > Timoth?e Lecomte wrote: > > > >> * There's another option : we can remove both 'subdir-objects' in > >> src/Makefile.am and AM_PROG_CC_C_O in configure.in > >> Then, wxt_gui.o and gp_cairo.o will be put in src/ instead of > >> src/wxterminal/, but I can definitely live with that. > >> > >> So, what's your preference ? > > > > The above. > > Ok, I agree. I will make this change soon, unless Lars does it before me. Fine by me. I'll hold off the other changes until after. |
|
From: Lars H. <lhe...@us...> - 2006-05-19 08:24:41
|
> > Ok, I agree. I will make this change soon, unless Lars does it before me. > > Fine by me. I'll hold off the other changes until after. There is another alternative, which will obsolete some of the changes I made on top of yours - making src/wxterminal a full autotoolified directory with its own Makefile.am. I prefer this, and will make the necessary changes. |
|
From: <tim...@en...> - 2006-05-19 16:28:08
|
> >> > Ok, I agree. I will make this change soon, unless Lars does it befor= e >> me. >> >> Fine by me. I'll hold off the other changes until after. > > There is another alternative, which will obsolete some of the changes = I > made > on top of yours - making src/wxterminal a full autotoolified directory > with > its own Makefile.am. I prefer this, and will make the necessary change= s. Oh, yes, that would be ideal ! I tried to do it at first (long before the commit) but my autoconf/automake skills were (are?) not enough... Thank you very much. Timoth=E9e |
|
From: Lars H. <lhe...@us...> - 2006-05-19 16:46:36
|
> > on top of yours - making src/wxterminal a full autotoolified directory > > with > > its own Makefile.am. I prefer this, and will make the necessary changes. > > Oh, yes, that would be ideal ! I tried to do it at first (long before the > commit) but my autoconf/automake skills were (are?) not enough... > Thank you very much. No problem. I won't be able to get to it before next week, though. |
