================ Comment at: include/__config:735-741 @@ -734,2 +734,9 @@ +// CloudABI is intended for running networked services. Processes do not +// have standard input and output channels. +#ifdef __CloudABI__ +#define _LIBCPP_HAS_NO_STDIN +#define _LIBCPP_HAS_NO_STDOUT +#endif + #if defined(__ANDROID__) || defined(__CloudABI__) ---------------- EricWF wrote: > jroelofs wrote: > > EricWF wrote: > > > What I like about `_LIBCPP_HAS_NO_MONOTONIC_CLOCK` and > > > `_LIBCPP_HAS_NO_THREADS` is that they must be explicitly defined be the > > > user. We don't automatically provide those configurations by way of the > > > `__config` header. I like this because those flags make libc++ become a > > > non-conforming standard library. > > > > > > Along the same vein I'm not sure I like `__config` having configuration > > > paths that make libc++ non-conforming. I understand why this is done in > > > the case of `__CloudABI__` and I'm not objecting. I just want to air my > > > uneasiness. > > > What I like about _LIBCPP_HAS_NO_MONOTONIC_CLOCK and > > > _LIBCPP_HAS_NO_THREADS is that they must be explicitly defined be the > > > user. > > > > I can see the reasoning behind it, but this is really inconvenient for me. > > The problem is that it's not reasonable to expect my users to `#define` > > these things, so locally I added a `<__config_site>` that `#define`s > > `_LIBCPP_HAS_NO_MONOTONIC_CLOCK` and `_LIBCPP_HAS_NO_THREADS`, which is > > `#include`d at the top of `<__config>`. > > > > I didn't realize this before, but I think the best way forward here would > > be to have cmake generate the `<__config_site>`, and stick it in an > > `include` dir in the build directory. Then at install time, have it copy > > that file to the install dir. This would have the added benefit of making > > the `-D_LIBCPP_HAS_NO_THREADS=1` things in `config.py` go away. > > > > How does that sound, @ericwf? > I like the idea of that but I'm not sure it helps fix this problem per se > since it still allows for implicit non-conforming configurations (although I > greatly sympathize with the rational for it) I would want to run it by > @mclow.lists first. I've thought about this before and my main concern is > that it would make reproducing bugs a lot more difficult because every user > has a different `<__config_site>` header. > > Perhaps we allow for a `<__config_site>` header to be used, but we only ever > provide an empty one with a big comment at the top warning users about > modifying it. Then if somebody really needs one of these configurations they > can go take the time to manually fill it out with the required definitions. > This would make it trickier to use the header in a regular build/test > workflow though. This would be something that is completely generated from the cmake configure line. I don't think it would change the repro steps at all because we'd already have to know what their configure line was.
The added benefit here is that it would keep a record on the end user's system of what flags their libc++ library was built with. http://reviews.llvm.org/D8340 EMAIL PREFERENCES http://reviews.llvm.org/settings/panel/emailpreferences/ _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
