[Python-bugs-list] [ python-Bugs-458343 ] distutils should zap .o as well as .so

[noreply@sourceforge.net]

Bugs item #458343, was opened at 2001-09-04 04:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=458343&group_id=5470

Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: A.M. Kuchling (akuchling)
Summary: distutils should zap .o as well as .so

Initial Comment:
Just rebuilt from CVS and got this toward the end:

  skipping 'pyexpat' extension (up-to-date)
  WARNING: removing "pyexpat" since importing it failed

It would have been nice to know why the import failed.
Also, instead of just deleting the .so file it should
delete the .o file as well.  In this case, deleting the
.o file to force recompilation instead of just
relinking solved the problem.

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

>Comment By: Skip Montanaro (montanaro)
Date: 2001-09-04 20:41

Message:
Logged In: YES 
user_id=44345

> Unfortunately, setup doen't honor dependencies, ...

While Distutils is a very clever piece of software, I have
always had this sneaking suspicion that it was trying to do
too much, subsuming some or all of the roles of make,
autoconf, libtool, etc.  In this particular case, the more I
think about it, the more I think it has to delete the .o
file.  When import of the .so fails, setup.py has no idea
why it failed, just that something's amiss.  It might have
been overly aggressive compiler switches, missing shared
libraries, or other things, so to be on the safe side it
should delete the .so file and any .o files that were
compiled to create the module that failed to load. 

The GNU build tools have progressed quite a way in the past
couple years, including improvements in portability (I
believe some or all of them will run on Windows now, at
least in certain configurations, like cygwin).  While their
output can be hell to debug, they do a much more complete
job of dependency analysis than setup.py.



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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-09-04 13:57

Message:
Logged In: YES 
user_id=6380

> when working from
> CVS it doesn't seem to me like I should always need
> to "make  clean",
> presuming the make dependencies are done right.

Unfortunately, setup doen't honor dependencies, and when a
header file has changed that affects the extensions, you
have to manually remove the build subdirectory (I do "rm -rf
build" :-) to get this to work.

I wish that this could be fixed too.

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

Comment By: Skip Montanaro (montanaro)
Date: 2001-09-04 13:20

Message:
Logged In: YES 
user_id=44345

> what did you use to clean up *.so files that didn't clean
> up *.o files?

The usual:

    cvs up .
    cd build
    ../configure
    make

Maybe this won't be a problem for people who routinely
download tarballs and build afresh, but when working from
CVS it doesn't seem to me like I should always need to "make
clean", presuming the make dependencies are done right.

The only thing I'm suggesting is that if distutils performs
an import to see if the newly built .so file is okay and
finds that it isn't, it should delete both the .so file and
the .o file from which it was built.  The message it emits
indicates that it is already zapping the .so file.

Skip



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

Comment By: A.M. Kuchling (akuchling)
Date: 2001-09-04 12:46

Message:
Logged In: YES 
user_id=11375

I'm not clear on the problem here; what did you use to 
clean up *.so files that didn't clean up *.o files?  "make 
clean" runs rm `find -name *.o`, and "python setup.py 
clean" blows away an entire directory under build/, so 
both of those seem to be correct.  What were you using?



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

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