homepage

I reported this on the distutils-sig list and didn't receive 
any response. I'd be happy to provide a patch, but I'm not 
sure which way to go.
<http://mail.python.org/pipermail/distutils-sig/2003-
September/003414.html>
Here's something that I think should work:
% python setup.py --help clean
[...]
Options for 'clean' command:
 --build-base (-b) base build directory (default: 
'build.build-base')
% python setup.py clean -b ../builds
running clean
Nothing happens. This works, however:
% python setup.py build -b ../builds clean
running build
running build_py
running build_ext
running config
gcc -E -I/Library/Frameworks/Python.framework/Versions/
2.3/include/python2.3 -o_configtest.i _configtest.c
removing: _configtest.c _configtest.i
running clean
removing '../builds/temp.darwin-6.8-Power_Macintosh-2.3' 
(and everything under it)
The logic to set build_temp from build_base (-b) is only 
present in the build command, not in the clean command. 
The code to set this option runs from 
clean.set_undefined_options. But it's clean's build_base 
option which is set at the time, not build's, so it 
propagates an empty path.
The test command class I found posted to the distutils-sig 
mailing list has a workaround for the above problem, which 
looks like this:
 def finalize_options(self):
 build = self.distribution.get_command_obj('build')
 build_options = ('build_base', 'build_purelib', 
'build_platlib')
 for option in build_options:
 setattr(build, option, getattr(self, option))
 build.ensure_finalized()
 for option in build_options:
 setattr(self, option, getattr(build, option))
and doesn't call self.set_undefined_options at all, though 
the last three lines could be replaced by it.
There are several solutions I can think of:
- set_undefined_options should be changed to propagate 
set options to
 the source command object before calling 
src_cmd_obj.ensure_finalized.
- another method should be added to the cmd class, which 
does the above
 propagation then calls set_undefined_options.
- a workaround such as the one above should be placed in 
the
 distutils.command.clean.clean class.
Does this make sense? Unless there's a huge compatibility 
issue, I'd favor the first option, but my experience with 
distutils is limited.

Sorry for the long delay without reply. Thank you for the report, I’ll look into it in the following weeks. In distutils2, I think clean could use the configure command (#8254) or maybe it’ll be simpler to just set_undefined_options from build. I’ll ask Tarek whether we can backport this to distutils after it’s done.

This is actually already fixed. Thanks for the report nonetheless!

Good to know - thanks!

Where was this fixed? It is still a problem in Python 2.6.6.
For example, if I do: 
python setup.py build_ext --compiler=mingw32 build --build-platlib=build\win64
Then follow it up with:
python setup.py clean --build-base=build\win64 -a
This is what it does:
running clean
'build\lib.win-amd64-2.6' does not exist -- can't clean it
removing 'build\bdist.win-amd64' (and everything under it)
'build\scripts-2.6' does not exist -- can't clean it
As you can see, the base directory argument is ignored.

> Where was this fixed? It is still a problem in Python 2.6.6.
I assumed it was fixed after looking at the code: clean does take build-* options from the build command.
> For example, if I do: 
> python setup.py build_ext --compiler=mingw32 build --build-platlib=build\win64
> Then follow it up with:
> python setup.py clean --build-base=build\win64 -a
> This is what it does:
> running clean
> 'build\lib.win-amd64-2.6' does not exist -- can't clean it
> removing 'build\bdist.win-amd64' (and everything under it)
> 'build\scripts-2.6' does not exist -- can't clean it
> As you can see, the base directory argument is ignored.
I’m not sure if this is a distutils bug or if you have to use the same options (i.e. build-lib both times, not build-platlib then build-base). The original report used -b (build-base) for both commands, so I’ll turn that into a test (unless you’d like to do it?) to see if it works as intended or not.

Distutils is now deprecated (see PEP 632) and all tagged issues are being closed. From now until removal, only release blocking issues will be considered for distutils.
If this issue does not relate to distutils, please remove the component and reopen it. If you believe it still requires a fix, most likely the issue should be re-reported at https://github.com/pypa/setuptools