[Python-bugs-list] [ python-Bugs-481972 ] Explanation of installation
noreply@sourceforge.net
noreply@sourceforge.net
Thu, 29 Nov 2001 15:06:08 -0800
Bugs item #481972, was opened at 2001-11-14 21:19
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=481972&group_id=5470
Category: Installation
Group: Feature Request
Status: Closed
Resolution: Works For Me
Priority: 5
Submitted By: David Abrahams (david_abrahams)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Explanation of installation
Initial Comment:
Can someone describe for me the relationship between
the directory structure that comes in the source
distribution and what I get on my disk when installed
under Windows? Some things are not in the same place,
and I can't make rhyme nor reason of it.
Thanks,
Dave
david.abrahams@rcn.com
----------------------------------------------------------------------
>Comment By: Tim Peters (tim_one)
Date: 2001-11-29 15:06
Message:
Logged In: YES
user_id=31435
Thanks for the info, MAL! If I'm reading it right, on
Windows you use an installation tree (rather than the
Windows Python build tree -- it doesn't sound like you
compile Python itself on Windows).
----------------------------------------------------------------------
Comment By: M.-A. Lemburg (lemburg)
Date: 2001-11-28 06:24
Message:
Logged In: YES
user_id=38388
BTW, you'll find a whole bunch of tools to "find" the Python
installation in distutils.
Closing the report since I don't see any point leaving it
open ;-)
----------------------------------------------------------------------
Comment By: M.-A. Lemburg (lemburg)
Date: 2001-11-26 05:27
Message:
Logged In: YES
user_id=38388
Here's a summary of what I do to support the mx Extensions for multiple Python versions:
Note: I use distutils on all platforms and distutils has builtin ways to find where the specific Python version I am
targetting lives.
On Unix:
Since the only binary format distutils currently support is RPM, this is only relevant to the bdist_rpm command.
Unfortunately, RPM does not inherit the environment, so you have to hard-code the path to the Python version into
the RPM. It goes something like this:
$(PYTHON) setup.py bdist_rpm \
--python $(PYTHON) \
--release $(PACKAGERELEASE) \
$(_RPM_REQUIRES)
On Windows:
Here, you have to run the setup.py file using the Python version you wish to build for, e.g. python2.0 setup.py
bdist_win. I choose the Python version by hacking the PATH to point to the right version (this is needed to have
sub-processes use the same Python version), e.g. wininst20.bat:
@echo off
call vcvars32
echo --------------------------------------------------------------
echo Building for Python 2.0...
set PATH="d:\Python20;%PATH%"
python setup.py clean --all
python setup.py bdist_wininst -c -o
That's about it. Hope it helps.
----------------------------------------------------------------------
Comment By: Tim Peters (tim_one)
Date: 2001-11-23 18:16
Message:
Logged In: YES
user_id=31435
It clarifies the problem but mainly in the sense of
clarifying that it *is* a problem: we don't require, or
even recommend, any particular way of building extensions.
IOW, "but I can't be certain" is correct, but not for a
reason I can do anything about except to confirm that it's
the truth. Marc-Andre Lemburg is our most prolific
extension writer, so I'm reassigning this to him in the
hope he'll explain what *he* does. You could do a lot
worse than catering to whatever that is.
----------------------------------------------------------------------
Comment By: David Abrahams (david_abrahams)
Date: 2001-11-15 15:34
Message:
Logged In: YES
user_id=52572
The problem goes something like this: Assume I have a nice,
generalized build system (I do, but not as nice as it will
be soon ;-)), to which I want to add Python support. I want
it to be possible to compile/test code against multiple
Python versions, though that's not too relevant to the
problem. I'd like finding the neccessary components
(headers, libs, executables) to be relatively automatic,
based on, e.g. the user's specification of a python base
directory and a version number. On Unices it should be
possible to do without the base directory unless python was
configured --with-prefix=....
I have to assume that someone developing Python extension
modules may either be using the source tree, or an
installation specific to to the platform he's developing
on. Someone who's just building an extension module is
probably using a Python installation, but I can't be
certain.
So, does that clear things up a bit?
-Dave
----------------------------------------------------------------------
Comment By: Tim Peters (tim_one)
Date: 2001-11-15 15:15
Message:
Logged In: YES
user_id=31435
The source distro is just a snapshot of Python's CVS
development tree, so it's a build tree, not an installation
tree. "The std" Windows installation tree is the one
created by the PythonLabs Windows installer. Similar
Windows trees are created by the ActiveState and PythonWare
Windows installers. "The std" Unix installation tree is
whatever the heck "make install" does on Unix (and it's not
the *build* tree either). Likewise for Macs, which
rearrage the build tree in yet other ways for installation.
The relationship between the build tree and the Windows
installation tree is established by the 3000-line
python20.wse script in PCbuild, which is input to the Wise
installer-builder; I can't summarize it usefully here, and
Windows installation also involves fiddling with registry
entries.
Afraid I'm still not clear on why you're asking, although
I'm quite sure I'm not really helping <wink>.
----------------------------------------------------------------------
Comment By: David Abrahams (david_abrahams)
Date: 2001-11-15 04:12
Message:
Logged In: YES
user_id=52572
Hi Tim,
Usually I install using the windows installer, and
eventually need to get the source so I download it
elsewhere; then I usually need the "_d" version so I build
that from the source. The two "installations" seem
different to me, and I'm not certain of all the ways in
which they differ. Just for example, when I build on
Windows, the executable(s) end up in the PCBuild
subdirectory. Is there a standard for how a Windows
installation should look?
Why do I care? I've been making a build/test install
system, which needs to link with/invoke python.
Thanks,
Dave
----------------------------------------------------------------------
Comment By: Tim Peters (tim_one)
Date: 2001-11-14 21:39
Message:
Logged In: YES
user_id=31435
David, I'm not clear on what "installed" means to you. Are
you building from source yourself, or using the PythonLabs
Windows installer? If the latter, the Windows distribution
is a precompiled distribution of a subset of the source
tree, plus a number of precompiled "external" packages
(like bsddb, zlib, expat, and Tcl/Tk). The Python source
distro is pruned on Windows to reflect that a vast majority
of our Windows users have no compiler, and no interest in
anything outside of Lib/ and a few of the Tools/
directories.
----------------------------------------------------------------------
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=481972&group_id=5470