| msg12956 - (view) |
Author: Philip Brown (theferret) |
Date: 2002-10-27 07:10 |
| 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 |
|
|
| msg12957 - (view) |
Author: Martin v. Löwis (loewis) *  |
Date: 2002-10-27 12:20 |
| 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. |
|
|
| msg12958 - (view) |
Author: Philip Brown (theferret) |
Date: 2002-10-27 18:51 |
| 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,ratherthantohardcodefor/usr/localAdditionally,therecouldconceptuallybeotherstuffin/usr/localthatmightconflict(whichactuallyhappendtome)Thewholepointof−−prefixistospecifyalocationtouseINSTEADOF/usr/local.Iftheuser/adminexplicitlysays"donotuse/usr/local,usethispathinstead",youshouldNOTuse/usr/local!!(unlessitisinprefix, 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 prefix,ratherthantohardcodefor/usr/localAdditionally,therecouldconceptuallybeotherstuffin/usr/localthatmightconflict(whichactuallyhappendtome)Thewholepointof−−prefixistospecifyalocationtouseINSTEADOF/usr/local.Iftheuser/adminexplicitlysays"donotuse/usr/local,usethispathinstead",youshouldNOTuse/usr/local!!(unlessitisinPATH, CPPFLAGS,orCPPFLAGS, or CPPFLAGS,orLD_LIBRARY_PATH. Which it is not, in my case) |
|
|
| msg12959 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2002-10-27 18:54 |
| 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] |
|
|
| msg12960 - (view) |
Author: Philip Brown (theferret) |
Date: 2002-10-27 19:27 |
| 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 |
|
|
| msg12961 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2002-10-27 19:36 |
| Logged In: YES user_id=21627 What's wrong with editing Modules/Setup? |
|
|
| msg12962 - (view) |
Author: Philip Brown (theferret) |
Date: 2002-10-28 01:53 |
| 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. |
|
|
| msg12963 - (view) |
Author: Facundo Batista (facundobatista) * |
Date: 2004-11-08 23:56 |
| 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 |
|
|
| msg12964 - (view) |
Author: Facundo Batista (facundobatista) * |
Date: 2005-01-15 21:32 |
| Logged In: YES user_id=752496 Deprecated. Reopen only if still happens in 2.3 or newer. . Facundo |
|
|