[webkit-dev] Fwd: Port WebKit to GNUstep

[Konstantin Tokarev]

12.05.2017, 17:03, "Daniel Ferreira (theiostream)" <bnmvco at gmail.com>:
> On Thu, May 11, 2017 at 11:58 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:
>>  Are you intending to maintain this port going forward? The bar for
>>  introducing a new port in the WebKit repository is pretty high due to
>>  the maintenance cost it incurs to all other contributors. Unless
>>  you're intending to maintain your own port, and then contribute to the
>>  rest of the WebKit project unrelated to your port work, we kindly ask
>>  you to maintain your port in some downstream repository such as a
>>  GitHub fork.
>>  - R. Niwa
>
> This is a very fair request – and thank you for specifying what "the
> bar is higher" actually means. This was very unclear from the previous
> response. 1) I do not intend to cause any liability to the project; 2)
> Becoming a WebKit contributor is not a scenario I discard depending on
> the outcome of this (since I naturally hope to learn about the
> project's internal APIs and other needs over this effort), but anyway,
> I don't believe this is the place to talk about personal involvement
> matters.
>
> That being said, I'd like to address a couple of issues that go beyond
> GNUstep and that are actual issues for building the Mac port on
> non-Darwin hosts, even if we hypothetically had Cocoa seamlessly
> running on Linux (which is an issue that transcends GNUstep, with a
> lot of good work being done on things like swift-corelibs-foundation).
>
> The first issue is with MemoryPressureHandlerCocoa.mm. We compile that
> automatically if we are building a Mac port, and we don't check for
> OS(DARWIN) before relying on Mach API headers (which naturally breaks
> everything). It seems like we should take that into account before
> just compiling the file, and if we discover we are on OS(LINUX), we
> should build the Linux pressure handlers instead. If that does in fact
> work is another question, and most likely would require adjustments.

Choice of the correct MemoryPressureHandler implementation can be done
in your Platform*.cmake

Note that you don't need to duplicate PlatformMac files and make changes,
it would be wiser to include(PlatformMac.cmake) and then make modifications
to variables.

>
> In my experiment, I built the Linux pressure handler instead of the
> Mac one and had to do this tweak:
>
> Index: wtf/linux/MemoryPressureHandlerLinux.cpp
> ===================================================================
> --- wtf/linux/MemoryPressureHandlerLinux.cpp (revision 214620)
> +++ wtf/linux/MemoryPressureHandlerLinux.cpp (working copy)
> @@ -117,7 +117,7 @@
>      }, this, nullptr);
>      g_source_attach(m_source.get(), nullptr);
>  #else
> - m_threadID = createThread("WTF: MemoryPressureHandler", [this] {
> readAndNotify(); }
> + m_threadID = createThread("WTF: MemoryPressureHandler", [this] {
> readAndNotify(); });
>
>  #endif
>  }
> ---
>
> We have a missing ')' here. Apparently no one ever had a build
> configuration that preprocessor-branched here.

You need to update your patches to current trunk, this code was changed
and now it has balanced parentheses.

>
> The other issue was related to the main thread code. On
> MainThread.cpp, we check for !OS(DARWIN) to define a isMainThread()
> symbol. If we build the Mac port with a non-Darwin-OS configuration,
> we get duplicated symbols from MainThreadMac.mm. This is another issue
> with assuming Mac port means OS(DARWIN), and we should do due
> adjustments to MainThreadMac.mm to handle this case (this time I'm not
> quite sure how that would be done).
>
> Another issue with MainThreadMac.mm is its assumption that
> pthread_main_np() will be available (it is not on Linux). I managed to
> get it working by applying this hack, borrowed from a Linux port of
> libdispatch:
>
> Index: wtf/mac/MainThreadMac.mm
> ===================================================================
> --- wtf/mac/MainThreadMac.mm (revision 214620)
> +++ wtf/mac/MainThreadMac.mm (working copy)
> @@ -37,6 +37,17 @@
>  #import <wtf/HashSet.h>
>  #import <wtf/Threading.h>
>
> +#if __linux__
> +#include <unistd.h>
> +#include <sys/syscall.h>
> +#include <sys/types.h>
> +
> +static inline int pthread_main_np()
> +{
> + return syscall(SYS_gettid) == getpid() ? 1 : 0;
> +}
> +#endif
> +
>
>  #if USE(WEB_THREAD)
>  #include <wtf/ios/WebCoreThread.h>
>  #endif
> ---
>
> Again, this is another issue that needs to be solved with some more
> elaborate checks for OS(DARWIN) and handling the non-Darwin cases.

I think it's not appropriate to put OS(LINUX) stuff to *Mac files. However,
it might be ok to rename/move some files to reflect contents better, e.g.
mac/MainThreadMac.mm could become cocoa/MainThreadCocoa.mm
(but people working on Mac port may disagree)

>
> I'd really appreciate comments on these issues, and thank you for the
> quick responses.
>
> -- Daniel.
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

-- 
Regards,
Konstantin