[Patches] [ python-Patches-460751 ] --with-shared: python with shared lib

noreply@sourceforge.net noreply@sourceforge.net
Wed, 12 Sep 2001 18:36:51 -0700


Patches item #460751, was opened at 2001-09-11 14:29
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460751&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Frederic Giacometti (giacometti)
Assigned to: Nobody/Anonymous (nobody)
Summary: --with-shared: python with shared lib

Initial Comment:
As a follow up to patch 400938
(https://sourceforge.net/tracker/?group_id=5470&atid=305470&func=detail&aid=400938),
here is an implementation of the --with-shared
configure option for building python on Posix systems
as a shared library.

Building python as shared library is activated with the
--with-shared option on ./configure

The following points are drawn to particular attention:

- A configbuild.py module is generated and placed in
the machine-dependent directory. It records most 
Python/Makefile variables (CC, CFLAG, LDSHARED...), and
make them available in Python.

- The build has been tested on:
   Linux2: OK
   SunOS5: OK
   IRIX64: Build OK, crash on test (bus error)

- Inference with distutils: I found it very difficult
understanding the distutil architecture and finding the
right points of change; I minimized my interaction
there. Furthermore, the availability of the
'configbuild' module overlaps some of the distutils;
but 'configbuild' is very easy to use ...

- Unresolved symbols: I turned on the symbol checking
flags whenever possible, on behalf the its better
generating the error on build than at runtime.

- configure.in: I only edited the configure Bourne
script, and did not bother with configure.in (actually,
I deleted it) and its autoconfig/m4 macro comparses.

Frederic Giacometti





----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-09-12 18:36

Message:
Logged In: YES 
user_id=6380

> What is the point of keeping using the autoconf thing when
> it is easier to maintain configure directly, than going
> through configure.in ?

But it's not. One line of configure.in often expands to
dozens (occasionally hundreds) of lines of configure.
autoconf has arcane knowledge that gets updated with new
autoconf releases.

You are entitled to your opinion, but in this case, it's
wrong. Go fork your own version of Python if you don't want
to learn autoconf.

----------------------------------------------------------------------

Comment By: Frederic Giacometti (giacometti)
Date: 2001-09-12 16:06

Message:
Logged In: YES 
user_id=93657

I am not willing  to make anything difficult for anybody,
but:

What is the point of keeping using the autoconf thing when
it is easier to maintain configure directly, than going
through configure.in ?

After configure has been generated once, it makes more sense
to me to work directly on configure, and forget about
configure.in.
configure (pure Bourne shell) is a easier to understand, to
troubleshoot, and to maintain that configure.in (a mixture
of Bourne shell and autoconf m4 macros).

I'll have a second look at the autoconf thing latter  on -
at present I hardly understand anything to configure.in, and
got 'configure --with-shared' working with satisfaction
across multiple platforms without undue difficulties.






----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-09-12 11:37

Message:
Logged In: YES 
user_id=6380

> Autoconf is not installed on the commercial Unix
> platforms, it is useless for me to learn it, and I was
> better off directly editing ./configure. However, if
others
> are familiar with the tool, it should be straightforward
for
> them to retrocede the changes from configure to
configure.in

Sure. You'll just have to wait until we have time for that.
You can make it easy for us to integrate your changes, or
you can make it difficult. Your choice.

----------------------------------------------------------------------

Comment By: Frederic Giacometti (giacometti)
Date: 2001-09-12 11:12

Message:
Logged In: YES 
user_id=93657


- I will remove the configbuild; since Martin pointed to me
the existence of  distutils.sysconfig.get_config_vars(). I
did not know about this function... Thanks!
On the fly, you'll also note the following potential problem
with using get_config_vars() instead of configbuild: 
configbuild will report the actual values used for the
build, whereas get_config_vars() will report erroneous
values whenever the Makefile internal variables were
overriden at build time (by either the environment, or by
commandline assignment of the type 'make CC=gxx ...'); not
to mention that configbuild does not need to find and parse
the original Makefile (with all the potential problems
associated).

- The .purify line should be in the CVSROOT/cvsignore CVS
admin file, not in .cvsignore in the root directory of the
source distribution...

- Autoconf is not installed on the commercial Unix
platforms, it is useless for me to learn it, and I was
better off directly editing ./configure. However, if others
are familiar with the tool, it should be straightforward for
them to retrocede the changes from configure to configure.in

- I had to introduce THREADOBJ because you will note that,
in the present implementation, Modules/thread.o appears
multiple times in  LIBOBJS, which causes warning at link
time. Now, Modules/thread.o appears only once




----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-09-12 01:06

Message:
Logged In: YES 
user_id=21627

As for libtool: I strongly advise not to use it. It is
broken in too many ways to enumerate.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-09-12 00:18

Message:
Logged In: YES 
user_id=21627

I recommend to rework this patch to get rid of 
configbuild. I cannot see what you achieve with the 
configbuild module that you couldn't do with 
distutils.sysconfig.get_config_vars (which is capable of 
parsing the Makefile directly).

I also recommend to go through the patch chunk by chunk, 
asking yourself whether this chunk *really* is needed to 
achieve the desired functionality. E.g. I cannot see the 
relationship of the .cvsignore chunk; I also believe that 
removal of .purify is incorrect. Likewise, while I 
sympathize with the unresolved symbols change, I believe 
it is unrelated to the main objective of this patch 
(building Python shared).

What is the rationale for not changing configure.in? 
As-is, this patch is useless: configure will be 
overwritten everytime you run autoconf. Please get a copy 
of autoconf on one of your systems, change configure.in, 
run autoconf, and then provide us with a patch that only 
changes configure.in: everybody reviewing this patch 
should be capable of running autoconf. configure is a 
generated file and should not be edited manually.

What is the rationale for the introduction of the 
THREADOBJ variable?



----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-09-11 19:03

Message:
Logged In: YES 
user_id=6380

Haven't seen the patch yet, but I like the idea -- the
command line option suggests that it shouldn't hurt
platforms where it can't be done or has to be done
differently.

Alternative: we could also consider using libtool. I didn't
like that much in the past, but maybe it would work. Dunno.
Anybody know about it?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460751&group_id=5470