Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

refactor: blaze::MakeDirectories should return std::error_condition #2149

Closed
laszlocsomor opened this issue Nov 30, 2016 · 2 comments
Closed

refactor: blaze::MakeDirectories should return std::error_condition #2149

laszlocsomor opened this issue Nov 30, 2016 · 2 comments
Assignees
@laszlocsomor
Labels
category: misc > misc P3 We're not considering working on this, but happy to review a PR. (No assignee) type: feature request
Milestone
post-1.0

Comments

@laszlocsomor
Copy link
Contributor

Instead of just a plain bool, this method (and maybe others in the blaze and blaze_util namespaces) could return a std::error_condition.

Filed on behalf of @abergmeier-dsfishlabs .
laszlocsomor referenced this issue Nov 30, 2016
@laszlocsomor @dslomov
Bazel client: reduce dependency on POSIX API
cefa9a2 
We can now compile blaze_util_windows.cc with
MSVC, yay! (when building //src:bazel
--cpu=x64_windows_msvc -k).

There are a lot of #ifdef's and TODOs so this
is a modest victory for now.

In this change:

- change blaze::MakeDirectories to return bool
instead of int, since that's how it was used
anyway, and to expect the permission mask as
unsigned int instead of mode_t, since the
former is good enough and compatible with
mode_t on POSIX while mode_t is not defined on
Windows

- move blaze::MakeDirectories into
blaze_util_<platform>

- implement envvar-handling in
blaze_util_<platform> and use it everywhere

See #2107

--
MOS_MIGRATED_REVID=139887503
@laszlocsomor laszlocsomor self-assigned this Nov 30, 2016
@abergmeier-dsfishlabs
Copy link
Contributor

@laszlocsomor Nice, thx.

@damienmg damienmg added P3 We're not considering working on this, but happy to review a PR. (No assignee) type: feature request labels Dec 12, 2016
@damienmg damienmg added this to the post-1.0 milestone Dec 12, 2016
@laszlocsomor
Copy link
Contributor Author

I don't think we'll every fix this, nor does it seem to bring any benefit.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@laszlocsomor laszlocsomor

Labels
category: misc > misc P3 We're not considering working on this, but happy to review a PR. (No assignee) type: feature request
Projects
None yet
Milestone
post-1.0
Development

No branches or pull requests
3 participants
@damienmg @laszlocsomor @abergmeier-dsfishlabs