Rename --out-dir to --artifact-dir
Progress towards unblocking #6790. Renames the experimental --out-dir argument to --artifact-dir, both to reflect that it's where the final build artifacts will be copied to, and to avoid confusion with the OUT_DIR environment variable which serves an entirely different purpose.
Existing users of the --out-dir argument and out-dir config.toml key will be redirected to --artifact-dir via a warning message.
Rationale
A lot of people seem to be confused by the naming of the --out-dir argument, and are misled into thinking it serves the same purpose as the OUT_DIR environment variable:
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @epage (or someone else) some time within the next two weeks.
Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:
-
@rustbot author: the review is finished, PR author should check the comments and take action accordingly -
@rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue
Grim news. Perhaps both flags must be briefly supported to deal with the bootstrap problem.
Never mind; it seems I was a bit zealous in replacing --out-dir and accidentally search-and-replaced it in some rustc invocations. Might still need to do some fixups but we're looking a lot better now.
This should be ready for review now. Not sure if this needs to go through any sort of design process since it's renaming a nightly-only API. There does seem to be some consensus in #6790 that --artifact-dir is a better name.
@epage Just wanted to make sure this hasn't fallen off your radar--it's ready for review now.
I have about a month backlog of github notifications that I still need to respond to.
Could you update the commits for how you'd want them presented for review and merging?
I've updated the flag-checking code and squashed most of the commits.
Should the deprecation messages provide some sort of warning that the old options will eventually be removed, or are they fine currently?
Thanks!
@bors r+
:pushpin: Commit 0aac3039563276f68e4c80c6962916b11ebb28b8 has been approved by epage
It is now in the queue for this repository.
:hourglass: Testing commit 0aac3039563276f68e4c80c6962916b11ebb28b8 with merge 4189f504aebc4b50612b6d6a071674cec9c7a2ff...
:sunny: Test successful - checks-actions Approved by: epage Pushing 4189f504aebc4b50612b6d6a071674cec9c7a2ff to master...