SCons
CopyTo()/CopyAs() not documented
This issue was originally created at: 2010-06-23 09:10:15.
This issue was reported by: gregnoel.
gregnoel said at 2010-06-23 09:10:15
I was responding to a user on IRC who was using Install() for an intermediate copy and I wanted to refer them to CopyTo() or CopyAs() and I couldn't find it in the documentation, either in the man page or the Users' Guide. Oops.
gregnoel said at 2010-06-24 05:27:07
Although the most important thing is to document CopyTo() and CopyAs(), I'm wondering if this might not be a good time for some consolidation. Install(), InstallAs(), Textfile(), and Substfile() are also "filesystem" builders, so they could be combined with CopyTo() and CopyAs() in filesystem.py.
It would have a small ripple effect in Tool/__init__.py (where the install builders are treated specially) but would only require loading one module instead of three, so it should make startup a bit faster.
gregnoel said at 2010-07-16 06:52:33
Bug party triage.
garyo said at 2012-09-01 10:01:49
Bumping all old issues targeted for past releases to 2.x.
These are still undocumented... anybody have any notes on them? There are no useful comments in Tool/filesystem.py which seems to be the only mention (except the use of CopyAs in packaging)
Turns out from a different set of work (see #3920) that the filesystem tool itself is also undocumented. This issue goes on to suggest some consolidation... any thoughts on this?
Turns out from a different set of work (see #3920) that the filesystem tool itself is also undocumented. This issue goes on to suggest some consolidation... any thoughts on this?
Install functionality and filesystem are really two different things. Though both are installed by default, I'm not sure there's a benefit to joining the two.
Documenting filesystem.py's builders/actions is worthwhile for sure.
install isn't default at the moment. filesystem (which provides CopyTo and CopyAs, whose only client, I believe, is Install) is, and recently, textfile/substfile became default. I think the thought was since all of these do "filesystem things" which don't use any external facilities (i.e. no commands to call out to, and thus to have to check for first) and their initialization is (comparatively) trivial, then they could all be in one tool module. I don't have strong feelings about it one way or the other.