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 _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com