Stronger cleaning with 'scons -cc' and 'scons -ccc'

[bdbaddog]

This issue was originally created at: 2007-02-24 14:47:39.
This issue was reported by: issues@scons.

issues@scons said at 2007-02-24 14:47:39

I make use of auto-configuration features of SCons 0.96.95, and it seems to work OK as long as you're building. However, when cleaning the build files with a scons -c, SCons will not remove the .sconf-temp/ directory or config.log file.

As an adjunct, it might be nice to also remove all .pyc files automatically too, since auto-config software is usually written in modules that are imported, thus generating Python .pyc files

Thanks.

stevenknight said at 2008-06-26 17:57:06

Set priority and target milestone per bug party.

gregnoel said at 2008-12-26 13:20:17

Adjust triage of issues.

gregnoel said at 2009-04-10 08:47:50

Redirecting this issue and changing the summary to reflect that.

There are two problems that SCons should solve here. The first one is to add stronger levels of clean to remove additional files and the second one is to allow the user to specify "lesser" levels of clean to remove files (perhaps produced as a side-effect or intermediate stage) that clutter directories or waste space.

The first step is to make the --clean option (-c) be accumulative, and add semantics for each level. This should be reviewed to see if additional levels might be needed, but the immediate proposal is to make scons -cc remove all configuration by-products (i.e., the configuration subdirectory), and other such files as the user might nominate (as with the .pyc files suggested by the original poster). Perhaps that's two levels right there, first user-suggested files for scons -cc then configuration by-products added for scons -ccc but that should be discussed. Adding a third (fourth?) -c option would remove the .sconsign file in addition.

Once that is done, this issue should be redirected once again (with another new summary!) to allow a user to specify "less than -c" levels of cleaning, maybe by attaching special actions to an alias. This could include the removal of intermediate products of normal build steps (e.g., the object files that are intermediates between sources and a library; if the library isn't going to be rebuilt frequently, the object files just waste space; see issue #583). It should be possible to identify these less-than-full-clean objects as a pattern that is expanded at clean time, in addition to the obvious lists; it should also be possible to specify clean actions as a dependency of a build step (i.e., clean a directory before regenerating it).

gregnoel said at 2009-04-10 08:48:02

*** Issue #1754 has been marked as a duplicate of this issue. ***

gregnoel said at 2009-04-10 08:48:23

*** Issue #2374 has been marked as a duplicate of this issue. ***

russel said at 2009-04-10 23:26:52

Really just signing up to this issue as a cc, but you have to make a comment it seems.

For one of my LaTeX "workflows", I end up having a:

Clean('.' , Glob('*~') , ['.sconsign.dblite']) 

so that I can give the command:

scons -c .

And get a "super clean". However, I find that in some situations this fails miserably -- but fortunately not in the one case where I really need it.

So I support having -cc and -ccc to get various levels of clean from SCons itself.

gregnoel said at 2009-04-11 06:15:49

As I am reminded by a post to the mailing list, the other thing that should have been mentioned is the ability to add an action (viz., "run a command") to a clean level in order to provide arbitrary semantics during a clean. The common request is the ability to run 'make clean' in a subdirectory that is still under control of autotools.

stevenknight said at 2009-11-10 18:00:19

stevenknight => issues@scons

gregnoel said this issue is duplicated by #1754 at 2009-04-10 08:48:02.

gregnoel said this issue is duplicated by #2374 at 2009-04-10 08:48:23.