[ python-Bugs-629345 ] build does not respect --prefix

[SourceForge.net]

Bugs item #629345, was opened at 2002-10-27 04:10
Message generated for change (Comment added) made by facundobatista
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=629345&group_id=5470

Category: Build
Group: Python 2.1.2
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Philip Brown (theferret)
Assigned to: Nobody/Anonymous (nobody)
Summary: build does not respect --prefix

Initial Comment:
I want to compile python with a different prefix.
I use configure --prefix=/my/stuf

but some things are still hardcoded to look in /usr/local

for example, setup.py

This stops extensions like bsddb from being built, even
though the include files are present in $prefix/include

Even if I go the extra mile to do export
CPPFLAGS=/my/stuff,
and the configure script successfully detects I have
db.h... 
it STILL does not compile bsddb until I make a link from
/my/stuff/include/db.h to /usr/local/include/db.h


Please fix all those locations that have hardcodes for
/usr/local




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

Comment By: Facundo Batista (facundobatista)
Date: 2005-01-15 18:32

Message:
Logged In: YES 
user_id=752496

Deprecated. Reopen only if still happens in 2.3 or newer. 

.    Facundo

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

Comment By: Facundo Batista (facundobatista)
Date: 2004-11-08 20:56

Message:
Logged In: YES 
user_id=752496

Please, could you verify if this problem persists in Python 2.3.4
or 2.4?

If yes, in which version? Can you provide a test case?

If the problem is solved, from which version?

Note that if you fail to answer in one month, I'll close this bug
as "Won't fix".

Thank you! 

.    Facundo

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

Comment By: Philip Brown (theferret)
Date: 2002-10-27 22:53

Message:
Logged In: YES 
user_id=7120

Whats wrong with editing Modules/Setup?

How about, "whats wrong with automating the build process in
a standard fashion, instead of forcing builders to jump
through unneccessary hoops?"

Thats what autoconf, etc. is for, after all.

LD_LIBRARY_PATH is a standard environment setting, across
virtually all modern UNIXen.

 Most other programs tend to compile a fake program, or some
such, to check for existance of a library

(like, $CC -o test test.c -ldb, and see if it works)

That is a fairly standard autoconf method of checking for
libraries, and has the nice side effect of taking advantage
of whatever dynamic loading paths the OS happens to use.

 If you are going to stick with your own methods of probing,
you should make those methods as effective as the more
common ones.

The way to DO that, is to respect LD_LIBRARY_PATH, if it is set.



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

Comment By: Martin v. Löwis (loewis)
Date: 2002-10-27 16:36

Message:
Logged In: YES 
user_id=21627

What's wrong with editing Modules/Setup?

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

Comment By: Philip Brown (theferret)
Date: 2002-10-27 16:27

Message:
Logged In: YES 
user_id=7120

When trying to detect whether a library is available, you
should at least respect LD_LIBRARY_PATH  if it is set,
rather than hardcoding stuff like /usr/local reguardless of
$prefix





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

Comment By: Martin v. Löwis (loewis)
Date: 2002-10-27 15:54

Message:
Logged In: YES 
user_id=21627

#--prefix specifies what to put in strings instead of
/usr/local.

No. See ./configure --help:

  --prefix=PREFIX         install architecture-independent
files in PREFIX
                          [/usr/local]


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

Comment By: Philip Brown (theferret)
Date: 2002-10-27 15:51

Message:
Logged In: YES 
user_id=7120

--prefix specifies what to put in strings instead of
/usr/local. It is common practice to install ALL free
software under a /usr/local equivalent. eg: /opt/freeware

Clearly, /opt/freeware is for ALL freeware, not just for
"this package".
It is the most consistent to scan whatever was specified for
$prefix, rather than to hardcode for /usr/local

Additionally, there could conceptually be other stuff in
/usr/local that might conflict (which actually happend to me)

The whole point of --prefix is to specify a location to use
INSTEAD OF /usr/local. If the user/admin explicitly says "do
not use /usr/local, use this path instead", you should NOT
use /usr/local !!

(unless it is in $PATH, $CPPFLAGS, or $LD_LIBRARY_PATH.
Which it is not, in my case)




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

Comment By: Martin v. Löwis (loewis)
Date: 2002-10-27 09:20

Message:
Logged In: YES 
user_id=21627

This is by design.

--prefix specifies the places to install *this* package
(i.e. python), not the places to look for other packages.

If you want to find libraries in different locations, edit
Modules/Setup appropriately; setup.py is not designed that case.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=629345&group_id=5470