Okay, there's just one more thing that I've found in 0.88 which makes it
balk on compilation, and I recognize it from the CVS build and simply
forgot I had to work aroung it. In the python plugin Makefile.am, the
INCLUDES variable declaration has the line '-I $(GTK_CFLAGS)', which (at
least on my RH7/GTK+ 1.2.10 system) gives an output of '-I-I
/usr/include/gtk-1.2 [...]'. The extra include directive causes gcc to
discard the rest of it, and I get errors about there being no file named
'gtk/gtk.h'. If the like in the makefile is changed to just say
'$(GTK_CFLAGS)', it compiles fine.
Sorry to not have remembered this before the .88 release; I guess it
must be a non-issue on some machines, anyway, so my conviction that
RH/Ximian is a brain-damaged combination seems to be holding up well.
Lennon Day-Reynolds
James Henstridge wrote:
>On Fri, 11 May 2001, Ben A. Hetland wrote:
>
>>James Henstridge wrote:
>>
>>>I have uploaded a dia-0.88 tarball that will be available at the following
>>>location once ftp.gnome.org syncs up:
>>> ftp://ftp.gnome.org/pub/GNOME/stable/sources/dia/dia-0.88.tar.{gz,bz2}
>>>
>>>This one has some more xfig fixes from Lars, and hopefully fixes all the
>>>build problems reported.
>>>
>>[...]
>>
>>>* updates to the python plugin and now distribute it with dia (--with-python)
>>>
>>I didn't test this tarball, but do these fixes also apply to the CVS
>>head?
>>
>
>I tagged the release as DIA_0_88 in CVS. The python-startup.py file I
>forgot to check in is there now.
>
>>The reason I ask is that I just did an update from CVS, and tryed to do
>>an 'autogen.sh' again, and I basically get the same problems related to
>>the PYTHON stuff that so many others have reported lately (including the
>>missing AM_PATH_PYTHON_JH).
>>
>
>You may be able to fix the problem by changing the lines like
> AC_REQUIRE([AM_PATH_PYTHON])
>to
> AC_REQUIRE([AM_PATH_PYTHON_JH])
>
>That may fix the problem for you. Note that in the tarball, the configure
>script has already been generated, so this isn't a problem. I tested
>builds with both python and gnome from the tarball (as well as a build
>with no configure switches), so the build problems are probably gone.
>
>>I didn't try to fix this or recover from the errors in any way, since
>>I'm too busy with other tasks at the moment (like you James, I
>>presume...). I just identified the problem still seemed to be present.
>>
>
>Thanks for your problem reports.
>
>James.
>
