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

[SourceForge.net]

Bugs item #640553, was opened at 2002-11-19 05:04
Message generated for change (Comment added) made by facundobatista
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: Facundo Batista (facundobatista)
Date: 2005-01-08 02:23

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: Nick Maclaren (nmm1)
Date: 2002-11-19 14:44

Message:
Logged In: YES 
user_id=652073

Well, that's an odd interpretation, but it isn't a great
matter.  However, I do feel that the "gotcha" should be
documented.  For example, the following perfectly reasonable
use will fail horribly on many systems:

A user version of a shareable library is in /usr/local/lib,
which
is a mountable filing system, and a system version in
/usr/lib,
which isn't - the former may be a symlink, or may be the
testing
version.  Python is built using the standard mechanism, and
is
then used for system scripts.  If those are then ever run
when
/usr/local is not mounted, they will fail horribly.

Incidentally, we got caught by that one by making /usr
mountable on one version of IRIX.  It was actually SGI
themselves who had missed the "gotcha", but we had the
problem :-(

Do what you will with this - I have resolved the issue
here.


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

Comment By: Skip Montanaro (montanaro)
Date: 2002-11-19 14: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 14: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 09: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 07: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