Does it make sense to have separate switches for `stdin` and `stdout`, as opposed to just "the standard streams"?
Or does CloudABI support `stderr`? ================ 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__) ---------------- jroelofs wrote: > 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. That sounds promising. Like @ErikWF, I am leery of making it convenient for users to (inadvertently, easily) build non-conforming versions of libc++ - for no reason other than the support questions/bug reports that filter back to us. 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
