[Scons-users] NoClean and node lists

[Robert Zeigler]

I appreciate the response and the time digging into the code.

The example I posted was, of course, a trivial one where the multi-targets can be separated; in practice, I have steps with multiple targets that are generated with a single command.

I’ve been giving it some thought and there is probably some wisdom in an “all-or-nothing” approach. If you clean a single target from the target list and rebuild, you’re going to wind up rebuilding all targets for the build step, anyway. So you may as well clean them all.

That said, it would be nice to be able to clean subsets. In my case, I have a build step where all targets are used as dependencies in downstream steps, but at the end the build, only a subset of those targets need to be retained long-term. I was hoping to use NoClean in conjunction with -c to  have a quick & easy way to clean out the build tree of all targets that aren’t needed long-term, retaining only the ones that are.

At least part of the “lazy” behavior is a bug.  Even if we want to retain the “all-or-nothing” behavior, right now, if some target other than the first target is listed as NoClean, all targets are cleaned anyway.

Robert

On Apr 26, 2014, at 4/264:42 AM , Dirk Bächle <tshortik at gmx.de> wrote:


> On 26.04.2014 11:29, Dirk Bächle wrote:

>> Hi Robert,

>> 

>> [...]

>> If I find the time, I'll dig into the code and try to find out why your approach doesn't work too.

>> 

>> Best regards,

>> 

>> Dirk

>> 

> 

> Okay, found it in "SCons/Scripts/Main.py" (CleanTask), ll. 353:

> 

>    def remove(self):

>        target = self.targets[0]

>        if (target.has_builder() or target.side_effect) and not target.noclean:

>            for t in self.targets:

>                try:

>                    removed = t.remove()

> 

> So, for multi-target builders SCons checks only the first one in the target list for the "NoClean" flag. Hmmm, now this looks a bit like a lazy hack to me.

> As your post clearly showed, a user would expect a different behaviour. Does anybody know of a situation where the current code actually makes sense, or should we file a bug report for this?

> 

> Regards,

> 

> Dirk

> 

> _______________________________________________

> Scons-users mailing list

> Scons-users at scons.org

> http://four.pairlist.net/mailman/listinfo/scons-users