[Patches] [ python-Patches-403678 ] setup.py.in
noreply@sourceforge.net
noreply@sourceforge.net
Mon, 21 May 2001 13:43:22 -0700
Patches item #403678, was updated on 2001-02-07 22:39
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403678&group_id=5470
Category: Build
Group: None
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Donn Cave (donnc)
Assigned to: A.M. Kuchling (akuchling)
Summary: setup.py.in
Initial Comment:
(Obsoletes part of #103487) Use the "configure" procedure for platform
specific values in setup.py. Build setup.py from setup.py.in - setup.cfg.in
was a nuisance anyway. The particular configure options for setup.py in
this patch are for BeOS, but it would be worth a look to see if some or all
of the USE_xxx options there should get in there, especially if controlled
by --with-xxx flags.
----------------------------------------------------------------------
>Comment By: A.M. Kuchling (akuchling)
Date: 2001-05-21 13:43
Message:
Logged In: YES
user_id=11375
Now irrelevant.
----------------------------------------------------------------------
Comment By: The Written Word (china) (tww-china)
Date: 2001-03-01 01:17
Message:
Logged In: YES
user_id=119770
I agree with donnc. We should definitely try and remove
platform-specific items, hard-coded paths, etc. from
setup.py. Let autoconf handle that. setup.py should be dumb
and driven by autoconf. We just ran into a situation where
we tried building 2.1CVS and wanted to feed -DUSE_SSL to
Modules/socketmodule.c. We're on a Solaris machine which
doesn't have libssl and libcrypto in the system linker
search path. So, we have to add -I<path> and -L<path>
options to the cc and ld line when Modules/socketmodule.c is
built. How do we do this with setup.py? Dunno. We currently
have a hack around this. I'd like a --with-ssl=<path> to
configure this at ./configure time and have that get passed
on to setup.py. Ditto for tk.
And, hard-coding /usr/local/include and /usr/local/lib is
just ugly.
Also, termios does not build "out of the box" under Solaris.
How do we disable this module?
----------------------------------------------------------------------
Comment By: Donn Cave (donnc)
Date: 2001-02-23 10:22
Message:
Yes, it's still waiting to be resolved. The patch
at least illustrates the problems (and of course it
would also solve them if applied.) I have been hoping
that you would put some thought into it, since your
sense of direction on it is at least clear enough to
know that it's different from where I would go. Since
there's plenty of specific information about what needs
to be done, I would prefer that you do at least something
for it, in setup.py. Then after you have wrestled with
the issues, I can check it out and see what you came up
with, and if necessary straighten out anything that doesn't
actually work.
If you want, I might be able to take a look at what it
would take to remove every single directory path literal
('/usr/X11R5', '/usr/lib/termcap', etc.), every platform
literal ('aix', 'sunos5', etc.) and every reference to a
platform specific flag ("linker_so + ' -shared' - what's
up with that?) and put it in configure if it's really
needed at all. Don't know if I could get that done for
2.1a3, but the sooner that gets cleaned up the better.
----------------------------------------------------------------------
Comment By: A.M. Kuchling (akuchling)
Date: 2001-02-23 08:37
Message:
Donn, is this patch still relevant? Do there remain BeOS-specific
issues to fix? Probably separate patches and bugs should
be opened to handle any outstanding problems.
----------------------------------------------------------------------
Comment By: Donn Cave (donnc)
Date: 2001-02-08 15:43
Message:
Not worried, just was trying to point out the good side of a
throw-away system for the dirty business of platform warts.
Anyway, with all that stuff to get done in setup.py, obviously
the release is a ways off yet.
----------------------------------------------------------------------
Comment By: M.-A. Lemburg (lemburg)
Date: 2001-02-08 14:51
Message:
Na, it's not higher, only in this case, the design is going in the
wrong direction. The new setup.py mechanism was meant to
allow as much automatic configuration as possible (previously
people had to edit Modules/Setup which was not difficult,
but obscure enough to keep people from enabling important
add-ons such as Tkinter). Now with the setup.py auto-detection
mechanisms in place, there should be much less user interaction
required to get a fully functional system.
As for the other patches: many of the Python core team are
currently out of town so there's a natural delay there. Nothing
to worry about though.
----------------------------------------------------------------------
Comment By: Donn Cave (donnc)
Date: 2001-02-08 11:16
Message:
I would be happy with extra symbols in Makefile, for
setup.py to use. I think this system will be somewhat
obscure for someone trying to figure out how to make
a build work, so some pointer comments at the top of
setup.py would be good. The last point there is not
so clear to me -- it sounds like there's an intent
to move a lot of logic from "configure" to setup.py.
I look forward to seeing whether that does give us much
more power and flexibility. It will put some pressure
on the Python code base, though - I already have changes
in for distutils and even os.py, to get through the build,
not to mention the two unsuccessful attempts to get changes
into setup.py. In 2.0, I came along pretty late in the beta
with changes that make it build for BeOS. Here I am right
at the beginning of 2.1 alpha, but the hurdle seems a lot
higher.
----------------------------------------------------------------------
Comment By: Neil Schemenauer (nascheme)
Date: 2001-02-08 10:45
Message:
One more reason for not using step.py.in or setup.cfg.in:
The Makefile is available to distutils when building
extension modules after the source is gone (ie. its
installed in lib).
----------------------------------------------------------------------
Comment By: M.-A. Lemburg (lemburg)
Date: 2001-02-08 10:29
Message:
I'd prefer if you'd put all the code into setup.py -- the tools are
all there. If you need extra symbols, then have configure place
them in the Makefile or config.h. Both are available for distutils
to use. Platform specifica can then be dealt with under Python's
control which gives you much more power and flexibility.
----------------------------------------------------------------------
Comment By: Donn Cave (donnc)
Date: 2001-02-08 10:12
Message:
That's OK with me, all I need is a place where I can
deal with platform specific issues, and it doesn't
matter a bit to me where. setup.py.in, Makefile,
setup.cfg, write the stuff right into setup.py
(e.g., if platform == 'Darwin'). What do you like?
----------------------------------------------------------------------
Comment By: A.M. Kuchling (akuchling)
Date: 2001-02-08 08:38
Message:
Agreed; generating Makefiles from the configure script is bad enough, and generating executable scripts is worse still. Reintroducing setup.cfg.in would be better, if that proves necessary.
----------------------------------------------------------------------
Comment By: M.-A. Lemburg (lemburg)
Date: 2001-02-08 05:01
Message:
Using setup.py.in is the wrong strategy here: you should consider
placing the symbols into the generated Makefile or config.h
and then have setup.py parse these files (the tools for this
are all there in distutils).
----------------------------------------------------------------------
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403678&group_id=5470