#13938 closed defect (fixed)
build: action=clean doesn't delete anything, and still builds
| Reported by: | Kenneth G. Franqueiro | Owned by: | Rawld Gill |
|---|---|---|---|
| Priority: | high | Milestone: | 1.7 |
| Component: | BuildSystem | Version: | 1.7.0b1 |
| Keywords: | build | Cc: | |
| Blocked By: | Blocking: |
Description
I suppose this is actually kind of 2 bugs in 1 report...
Firstly, action=clean doesn't actually clean anything. If I'm looking in the right spot, util/build/discover.js:275 would lead me to believe that the code responsible for actually deleting is commented out. I'm not sure whether there's a legitimate reason for this (i.e. it's unfinished or untested).
Secondly, in 1.6 if I were to ./build.sh profile=something action=clean, it would simply clean out the release folder. In trunk, it still runs the build process (i.e. it behaves like I'd expect action=clean,release to behave).
Change History (4)
comment:1 Changed 8 years ago by
| Status: | new → assigned |
|---|
comment:4 Changed 8 years ago by
action clean has been removed because:
- It's not normal for a compiler-like program to delete subtrees on a file system.
- The builder is more like a compiler than a make system.
- The builder is now capable of compiling many disjoint subtrees and placing those in disjoint locations. Mistakes + clean could result in unintentional erasing of large parts of a disk drive.
If action=clean is specified, a message is given saying it has been removed and to use rm or rmdir.
Note: See
TracTickets for help on using
tickets.
action=clean will probably be removed in 1.7. Although the code exists, it is commented out. The idea of a compiler (which is basically what the build system is) deleting directory trees is extremely unusual and potentially dangerous. For example, if a user specified the input paths incorrectly, he could delete large portions of his disk unintentionally.
Looking into why action=clean does anything at all.