rlib-devel

[Rlib-devel] Python bindings problem

[Aldo N. B. <al...@gm...>]

Hi, I've had problems compiling rlib (lastest CVS) with python support on my
Debian Sid/PPC

I fixed the problems by adding a macro to acsite.m4 and modifying
configure.in and bindings/python/Makefile.am

I've attached the patch and the acsite.m4

I've also noticed that the config.h.in was missing from CVS
Also the documentation does not compile, I don't know exacty why. I've
attached the gzipped book.log

Best regards

--

Aldo Nicolas Bruno
Referente del LUG San Fidenzio - http://www.lugsanfidenzio.org/
Sviluppatore del progetto GEPAL - http://www.gepal.org/
Home page: http://aldox86.blogspot.com/

Re: [Rlib-devel] Python bindings problem

[Bob D. <bd...@si...>]

Hi,

Sorry for the delayed response.

First can you send patches in unified diff format so they are easier to
read.  (diff -u)

Your patch would break RLIB detecting if it should build Python
bindings.

Before I could apply the acsite.m4 stuff I would need to better
understand why it's better across distributions.  What's wrong w/ the
existing detection?

config.h.in is generated w/ autoheader when you run autogen.sh before
you build from CVS

I have no idea why the documentation does not compile :(  I am in the
process of moving all RLIB documentation to a wiki (newrlib.sicom.com)

Thanks!

- Bob

On Wed, 2005-12-28 at 15:59 +0100, Aldo Nicolas Bruno wrote:
> 
> Hi, I've had problems compiling rlib (lastest CVS) with python support
> on my Debian Sid/PPC
> 
> I fixed the problems by adding a macro to acsite.m4 and modifying
> configure.in and bindings/python/Makefile.am
> 
> I've attached the patch and the acsite.m4
> 
> I've also noticed that the config.h.in was missing from CVS
> Also the documentation does not compile, I don't know exacty why. I've
> attached the gzipped book.log
> 
> Best regards
> 
> -- 
> 
> Aldo Nicolas Bruno 
> Referente del LUG San Fidenzio - http://www.lugsanfidenzio.org/
> Sviluppatore del progetto GEPAL - http://www.gepal.org/
> Home page: http://aldox86.blogspot.com/
-- 
Bob Doan <bd...@si...>

Re: [Rlib-devel] Python bindings problem

[Aldo N. B. <al...@gm...>]

Hi,
sorry for the very delayed reply

On 1/1/06, Bob Doan <bd...@si...> wrote:
> Sorry for the delayed response.
no problem

> First can you send patches in unified diff format so they are easier to
> read.  (diff -u)
Ok sorry

> Your patch would break RLIB detecting if it should build Python
> bindings.
> Before I could apply the acsite.m4 stuff I would need to better
> understand why it's better across distributions.  What's wrong w/ the
> existing detection?
Sorry again I just used a system that was known to work well
I've corrected your version now, and it is much cleaner
hereis the patch:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D python.patch =3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

--- configure.in.orig=092006-01-31 01:36:16.000000000 +0100
+++ configure.in=092006-01-31 01:59:02.000000000 +0100
@@ -353,13 +353,30 @@
 PYTHON_CFLAGS=3D""
 PYTHON_EXTENSION_DIR=3D""
 if test x$enable_python =3D xyes; then
+
 =09AM_PATH_PYTHON($python_version)
-=09if test x$PYTHON_VERSION =3D x$python_version; then
-=09=09eval python_foo=3D$PYTHON_PREFIX
+=09
+=09## if test x$PYTHON_VERSION =3D x$python_version; then
+=09##what if the version is bigger?=09
+=09## remember that AM_PATH_PYTHON gives
+=09## a python version >=3D$python_version
+
+=09## we must check the PYTHON variable instead, like this:
+=09if test x$PYTHON !=3D x":"; then=09
+=09=09#eval python_foo=3D$PYTHON_PREFIX
+=09=09## PYTHON_PREFIX variable is not yet functional in Automake
+=09=09## now it just uses the value of ${prefix} :(
+=09=09## so when looking for Python.h, if the ${prefix} of the
+=09=09## application does not match with that of python
+=09=09## (say he have python installed under /usr and rlib
+=09=09## under /usr/local) and we'll mostly fail to compile.
+=09=09## we have to guess it by hand: Idea: the `dirname' command
+=09=09python_foo=3D`dirname $PYTHON`/..
+=09=09
 =09=09AC_CHECK_HEADERS($python_foo/include/python$PYTHON_VERSION/Python.h,=
python_header=3Dyes,python_header=3Dno)
 =09=09if test x$python_header =3D xyes; then
 =09=09=09AC_DEFINE(HAVE_PYTHON,1,[Build with PYTHON support])
-=09=09=09PYTHON_CFLAGS=3D"-I $PYTHON_PREFIX/include/python$PYTHON_VERSION"
+=09=09=09PYTHON_CFLAGS=3D"-I$python_foo/include/python$PYTHON_VERSION"
 =09=09=09PYTHON_EXTENSION_DIR=3D$pyexecdir
 =09=09else
 =09=09=09enable_python=3Dno

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D python.patch =3D=3D=
=3D=3D=3D=3D=3D=3D[end]=3D=3D=3D

> config.h.in is generated w/ autoheader when you run autogen.sh before
> you build from CVS
no, maybe that for you works, but not for me, I don't know exactly why.
I'be also tried to run autoheader manually, but it does not generate anythi=
ng
(I'm of course using the lastest CVS)

> I have no idea why the documentation does not compile :(  I am in the
> process of moving all RLIB documentation to a wiki (newrlib.sicom.com)
:(


Best regards,

aldox
--

Aldo Nicolas Bruno
Referente del LUG San Fidenzio - http://www.lugsanfidenzio.org/
Sviluppatore del progetto GEPAL - http://www.gepal.org/
Home page: http://aldox86.blogspot.com/
GPG Public Key:
http://keyserver.veridis.com:11371/export?id=3D-3100218920628447415

Re: [Rlib-devel] Python bindings problem

[Aldo N. B. <al...@gm...>]

On 1/31/06, Aldo Nicolas Bruno <al...@gm...> wrote:
> > config.h.in is generated w/ autoheader when you run autogen.sh before
> > you build from CVS
> no, maybe that for you works, but not for me, I don't know exactly why.
> I'be also tried to run autoheader manually, but it does not generate anyt=
hing
> (I'm of course using the lastest CVS)
>

I've fixed the problem: it seems that in some systems autoconf lacks of
acconfig.h. A possible fix maybe to always distribute it with the sources.
(in attachment the acconfig.h). It just worked for me.

Best regards,
aldox

--

Aldo Nicolas Bruno
Referente del LUG San Fidenzio - http://www.lugsanfidenzio.org/
Sviluppatore del progetto GEPAL - http://www.gepal.org/
Home page: http://aldox86.blogspot.com/
GPG Public Key:
http://keyserver.veridis.com:11371/export?id=3D-3100218920628447415