python 2.3.3 setup.py: why adding sys.prefix to include_dir, libdir?

[Michael Hudson]

"Holger Joukl" <Holger.Joukl at LBBW.de> writes:

> Hi there,
> 2 questions regarding build/installation issues:
> 
> 1. In the python 2.3.3 setup.py script, the detect_modules method of
> class PyBuildExt contains the following code:
> 
> 253         if os.path.normpath(sys.prefix) != '/usr':
> 254             add_dir_to_list(self.compiler.library_dirs,
> 255                             sysconfig.get_config_var("LIBDIR"))
> 256             add_dir_to_list(self.compiler.include_dirs,
> 257                             sysconfig.get_config_var("INCLUDEDIR"))
> 
> This basically just adds the PREFIX/lib and PREFIX/include to
> self.compiler.library_dirs
> and self.include_dirs, PREFIX being what I gave to configure as command
> line argument, e.g.:
> ./configure --prefix=/opt/tools --with-cxx=gcc
> 
> I understand the --prefix=PREFIX sets the installation _target_ directory.
> Does it make sense to have these paths in include_dirs/library_dirs? Why
> would I want this?

Well, to work completely out of the box setup.py would need to be
telepathic, omniscient and be able to see into the future.  We're
working on that <wink>, but not there yet.

So I wouldn't regard having to hand-hack setup.py as being in
particularly bad taste.

> In fact, as it turned out that I had some bogus header files in the
> PREFIX directory, an extension module would not compile.

Well, might I suggest not installing broken headers on your system?  I
mean, I can think of real reasons for not wanting $(prefix) on the
search path, but not this one.

> 2. As a lot of things do not live in the "standard" places in our
> environment, 

What is your environment, out of curiosity?

> there seem to be several places where I have to change setup.py
> manually. E.g. adding runtime library dirs for curses, gdbm etc.  Is
> there another way to achieve correct build, in terms of telling my
> non-standard paths to configure in the first place?

Er, no, or at least not in general.  Editing Modules/Setup is another
option...

> Just to spare me from changing setup.py...

... as is submitting patches to SF that make setup.py look in these
places, if they are in fact "standard" for your environment but not
for, say, Red Hat Linux.

Cheers,
mwh

-- 
  Never meddle in the affairs of NT. It is slow to boot and quick to
  crash.                                             -- Stephen Harris
               -- http://home.xnet.com/~raven/Sysadmin/ASR.Quotes.html