On Sun, Dec 27, 2020 at 7:20 AM Bruno Haible <br...@clisp.org> wrote: > > Hi Jeffrey, > > > Just an FYI in case you have not hit this wall (yet?)... The exec > > family, posix_spawn and friends are _not_ available on all Apple > > platforms. Be sure to check availability before using them. > > > > For example, the iPhone/iPad SDKs has them, but the WatchOS and TvOS > > SDKs lack them. To further complicate matters, you have to include > > <TargetConditionals.h> before you can check for the SDK. > > There are 3 questions: > > 1) Do you think it is technically possible to support the iOS variants > in Gnulib?
I think Yes, it is technically feasible in most instances. I think initial support can simply be recognizing the problem platforms and disabling code paths or returning ENOSYS (not implemented). I believe Apple wants folks to use NSTask or NSThread on AppleTV and AppleWatch. So there is an upgrade path for those who are initiated. > 2) Do you think it makes sense for the GNU project to support the iOS > variants? Well, I think iOS is one of the most popular platforms, so it would be wise to try to support it. Android has about 70% mobile market share, and iOS has about 28% mobile market share. I don't know the breakdown of iOS variants. But 28% is non-trivial, so I would try to support it. https://gs.statcounter.com/os-market-share/mobile/worldwide. iPhone and iPads should cause the least pain because they mostly behave like you expect. Gnulib and other GNU projects already support them. AppleTV and AppleWatch can be more painful because they are crippled. SOme programs and libraries won't have any problems. For those who are using a missing function, maybe initial support for them can be a replacement posix_spawn that simply returns ENOSYS. > 3) Do you think we need to document that Gnulib doesn't support the iOS > variants? Yes. It is a sharp edge. I imagine developers searching for "Gnulib posix_spawn iOS" or "Gnulib posix_spawn AppleTV" to see what is going on when they encounter a compile error. > My take on these questions would be: > > 1) For an OS that does not have files with file names, it's pointless to > even think about open(), exec(), and so on. For AppleTV and AppleWatch, I believe the crippled-ness is limited to forking a new process. That's why posix_spawn and the exec family are missing. I think you will be OK with the other operations, like file or socket ops. What I have found in practice is, the test suites have the most trouble because developers fork a server to test something related to a socket. The libraries and programs ported to AppleTV and AppleWatch are usually OK. > 2) Anyone buying and using these devices has surrendered their entire > freedom and privacy to Apple. There is no point for GNU to help make > these devices more widely spread by porting software to it. Yeah, I'm not a big fan of Apple either. I stopped joining their Developer Program years ago when they started forcing people into their iCloud and wanted folks to indemnify their officers. Buy a fucking insurance policy if you want indemnification... I now support Apple platforms to poke Apple in the eye. Anything I can do to make free software a better alternative is usually a high priority for me. > 3) I would think that the communities of POSIX / C users and iOS / Swift > users are disjoint. Hence no need to document. Yeah, I would document it for users. Documentation is cheap. The groups may be disjoint, but there's no sense in penalizing an iOS user because of what Apple does. At least let iOS users know there are technical limitations behind the lack of full support. Jeff
