[Python-bugs-list] [ python-Bugs-481972 ] Explanation of installation

noreply@sourceforge.net noreply@sourceforge.net
Fri, 30 Nov 2001 01:37:35 -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: M.-A. Lemburg (lemburg)
Date: 2001-11-30 01:37

Message:
Logged In: YES 
user_id=38388

Right. In fact, I've never compiled Python on Windows in all the years. You've done such a wonderful job that this 
simply isn't necessary :-)

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

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