Add a --clean option to the briefcase build command

[michelcrypt4d4mus]

I found myself wanting a quick way to wipe all build artifacts so I added a --clean option, as in briefcase build macOS Xcode --clean. Feel free to request changes or just close if that's not something the team is interested in.

PR Checklist:

• All new features have been tested (but there's no pytest test)
• All new features have been documented (appears in the --help output)
• I have read the CONTRIBUTING.md file
• I will abide by the code of conduct

edit: just to be clear, i will add unit tests if this is actually a feature people are interested in

[mhsmith]

Isn't this the same as re-running briefcase create?

[michelcrypt4d4mus]

Isn't this the same as re-running briefcase create?

almost but not quite - briefcase create will repopulate the directory whereas --clean just deletes it and leaves it deleted.

[freakboy3742]

Thanks for the suggestion; but I'm going to close this PR as WONTFIX.

I'm not really understanding why this is useful either. If you want to remove the build artefacts and not recreate them, you can use rm -rf build (or a subset of that folder if you just want to remove one project type). I don't see that we gain anything by complicating the Briefcase interface with something that can be done with basic file system management commands.

[michelcrypt4d4mus]

as a new user it was unclear to me where the build artifacts were and whether deleting dirs in build/ would actually remove all build artifacts. maybe it's an issue better solved with documentation but for me this is helpful in a very small way. (also as an aside most IDEs and build tools all the way back to classic make have a "Clean" option in their "Buiild" menu)

[freakboy3742]

FWIW: If we were to implement this, I'd be a lot more inclined to add a new top-level command - briefcase clean. This would be a lot closer to the make clean experience, and would allow us to target both build and dist artefacts in a platform-specific way (but, AFAICT, wouldn't require any platform-specific implementations). If you're interested in pursuing this, I'd suggest opening a ticket proposing the feature, rather than jumping directly to an implementation.

[michelcrypt4d4mus]

I'd suggest opening a ticket proposing the feature

I'm still not sure where these tickets are or how to propose a feature? i don't really care about this feature but i have a different thing i'd like to propose. the briefcase docs on contributing just say:

If you want to contribute code, please fork the code and submit a pull request.

so it seemed reasonable to begin a discussion with a PR. (i implemented it for my own local use, more as a way of reading the code to figure out where build artifacts are than anything)

[freakboy3742]

I'd suggest opening a ticket proposing the feature

I'm still not sure where these tickets are or how to propose a feature?

"Ticket" is another word commonly used to describe the "issues" on a repository - if you click on new issue, one of the options is a feature request.

If you want to contribute code, please fork the code and submit a pull request.

so it seemed reasonable to begin a discussion with a PR. (i implemented it for my own local use, more as a way of reading the code to figure out where build artifacts are than anything)

Admittedly, that document starts at the point where it's time to actually contribute code, and skips the process of designing a feature in the first place. Agreed that we could improve our documentation here. FWIW, the "open a feature request ticket to discuss a potential idea" is a workflow that is common to most GitHub projects, so it didn't occur to me that documenting this step would be necessary.