[PATCH] Make the presence of stdin and stdout optional

[Jonathan Roelofs]

================
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__)
----------------
mclow.lists wrote:
> 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.
> 
> 
We could add cmake `message(WARNING "Disabling FOO makes libc++ a non-conforming library")` when those get turned on, and also leave a note in the generated __config_site file saying roughly the same thing. That way the person building the library gets a warning that maybe they should re-consider what they're doing, and their end-user gets an easy answer for why there aren't any FOO symbols/declarations in the library/headers.

http://reviews.llvm.org/D8340

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/