make clean fails to delete .a and .so.X.Y files

[smontanaro]

BPO	4007
Nosy	@loewis, @birkenfeld, @vstinner, @devdanzin, @merwok

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2010-07-31.22:05:59.787>
created_at = <Date 2008-10-01.12:52:37.787>
labels = ['easy', 'type-bug', 'build']
title = 'make clean fails to delete .a and .so.X.Y files'
updated_at = <Date 2010-07-31.22:05:59.785>
user = 'https://github.com/smontanaro'

bugs.python.org fields:

activity = <Date 2010-07-31.22:05:59.785>
actor = 'georg.brandl'
assignee = 'none'
closed = True
closed_date = <Date 2010-07-31.22:05:59.787>
closer = 'georg.brandl'
components = ['Build']
creation = <Date 2008-10-01.12:52:37.787>
creator = 'skip.montanaro'
dependencies = []
files = []
hgrepos = []
issue_num = 4007
keywords = ['patch', 'easy']
message_count = 9.0
messages = ['74128', '102677', '102679', '102686', '102711', '105839', '105841', '106228', '112216']
nosy_count = 6.0
nosy_names = ['loewis', 'georg.brandl', 'vstinner', 'ajaksu2', 'eric.araujo', 'l0nwlf']
pr_nums = []
priority = 'normal'
resolution = 'accepted'
stage = 'needs patch'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue4007'
versions = ['Python 2.6', 'Python 3.1', 'Python 2.7']

[smontanaro]

The "clean" target in the makefile fails to delete the libpython.a file
and the libpython.so.X.Y file (should you have configured using
--enable-shared). The attached trivial patch solves that problem.
The patch is against the trunk as of just before the 2.6 final release.
It will almost certainly apply cleanly to the py3k version as well.

[devdanzin]

Skip, was there a patch here? I can't find it in the bug lists, so I think we both missed it?

Pinging Martin in case the tracker ate the patch :)

[loewis]

If it did eat the patch, we would have lost it by now: there is nothing in the history that shows that a file was attached at some point. More likely, Skip forgot to attach it when submitting this report.

[l0nwlf]

skip.montanaro forgot to attached the patch obviously, however the issue is trivial but there i.e. the presence of libpython.a file.

[smontanaro]

Martin> If it did eat the patch, we would have lost it by now: there is
Martin> nothing in the history that shows that a file was attached at
Martin> some point. More likely, Skip forgot to attach it when
Martin> submitting this report.

Yeah, I must have just forgotten to attach it. At one point I'm pretty sure
I had something in my sandbox, but have nothing now. Removing .a files is
pretty straightforward. Removing .so.X.Y files is a little more cumbersome
because globbing isn't perfect. This (only lightly tested) patch should be
good enough though:

Index: Makefile.pre.in
===================================================================
--- Makefile.pre.in (revision 79207)
+++ Makefile.pre.in (working copy)
@@ -1156,8 +1156,9 @@
find $(srcdir) -name '*.py[co]' -exec rm -f {} ';'

 clean: pycremoval
-       find . -name '*.o' -exec rm -f {} ';'
+       find . -name '*.[oa]' -exec rm -f {} ';'
        find . -name '*.s[ol]' -exec rm -f {} ';'
+       find . -name '*.so.[0-9]*.[0-9]*' -exec rm -f {} ';'
        find build -name 'fficonfig.h' -exec rm -f {} ';' || true
        find build -name 'fficonfig.py' -exec rm -f {} ';' || true
        -rm -f Lib/lib2to3/*Grammar*.pickle

even though the second addition would also match files like

Margaret.so.9a.1g4

Skip

[merwok]

Note: Using find -delete avoids the extra process spawning for rm. However, if the -f option is really necessary, we’ll have to use rm.

Someone has an idea about the imperfect regex/glob pattern?

[smontanaro]

> Note: Using find -delete avoids the extra process spawning for rm.

The -delete expression isn't universally available. For example, it is not
present on Solaris. Better just to stick with the reliable rm.

Skip

[vstinner]

Yes, "make clean" should remove *.a and *.so.* files. The patch looks ok.

[birkenfeld]

Applied in r83372.