[Python-bugs-list] [ python-Bugs-640553 ] Misuse of /usr/local/in setup.py

noreply@sourceforge.net noreply@sourceforge.net
Tue, 19 Nov 2002 09:38:46 -0800


Bugs item #640553, was opened at 2002-11-19 02:04
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=640553&group_id=5470

Category: Build
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Nick Maclaren (nmm1)
Assigned to: Nobody/Anonymous (nobody)
Summary: Misuse of /usr/local/in setup.py

Initial Comment:
I cannot guarantee that this has not been reported
before, as the search facility doesn't appear
sufficiently powerful to determine that, and I do not
have time to read a hundred bug reports.

setup.py forces the use of /usr/local, which is wrong
on more counts
than I can describe.  Not merely need it not exist, it
could easily
contain the wrong versions of libraries and headers. 
The following
change should be reversed:

*** setup.py.org        Mon Nov 18 19:57:09 2002
--- setup.py    Mon Nov 18 19:57:23 2002
***************
*** 197,207 ****
          return platform
  
      def detect_modules(self):
-         # Ensure that /usr/local is always used
-         if '/usr/local/lib' not in
self.compiler.library_dirs:
-             self.compiler.library_dirs.insert(0,
'/usr/local/lib')
-         if '/usr/local/include' not in
self.compiler.include_dirs:
-             self.compiler.include_dirs.insert(0,
'/usr/local/include' )
  
          try:
              have_unicode = unicode
--- 197,202 ----


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

>Comment By: Skip Montanaro (montanaro)
Date: 2002-11-19 11:38

Message:
Logged In: YES 
user_id=44345

Some compilers complain if -I/usr/local/include is on the command line because it 
changes the compiler's notion of include file search order.  The case -L/usr/local/lib 
may be similar.  If this was an ideal world, I think we would ask the compiler if it 
searches /usr/local by default.  If so, don't add the -I/-L flags.  Maybe there's an 
autoconf macro floating around that can do this?

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

Comment By: Martin v. L÷wis (loewis)
Date: 2002-11-19 11:05

Message:
Logged In: YES 
user_id=21627

If /usr/local/lib causes a build failure, then the
requirements are not absolutely standard, by (our)
definition: We require /usr/local/lib to provide any
libraries that are not normally on the system. Absence of
/usr/local/lib is not a problem, nor are missing libraries a
problem. 

If accessing /usr/local/lib alone causes catastrophic
failures, it can't be a standard system.

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

Comment By: Nick Maclaren (nmm1)
Date: 2002-11-19 06:29

Message:
Logged In: YES 
user_id=652073

No, that's not the issue.  The build was absolutely out of
the box, and the requirements were absolutely standard.
But, for reasons that are irrelevant, -L/usr/local/lib
caused failure.

The point was that I had not specified it, it was not
specified anywhere in the configuration or any of the
Makefiles, and it wasn't even in Modules/Setup!  So I
could not understand where it was being set.

I discovered that setup.py is invoked by default, and that
did the job but didn't leave a record in any configuration
or building file.  GOTCHA!



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

Comment By: Michael Hudson (mwh)
Date: 2002-11-19 04:00

Message:
Logged In: YES 
user_id=6656

It's not added if it doesn't exist in the HEAD branch.

Wrt the other complaint, I think setup.py is only intended
to be a convenience. If you have even vaguely complex
building requirements, edit Modules/Setup instead.

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

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