================ 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/ _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
