[Webkit-unassigned] [Bug 179814] [Win] forwarding headers should not be copies

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Nov 17 11:27:52 PST 2017


https://bugs.webkit.org/show_bug.cgi?id=179814

--- Comment #26 from Don Olmstead <don.olmstead at sony.com> ---
(In reply to Michael Catanzaro from comment #25)
> (In reply to Don Olmstead from comment #24)
> > (In reply to Konstantin Tokarev from comment #23)
> > > >Is there any reason why we shouldn’t just copy the headers in CMake ports?
> > > 
> > > You mean avoid copying? Because doing otherwise is a regression and leads to
> > > possible #pragma once problems described by Mark.
> > 
> > I'm saying why don't we fix what's wrong within CMake or whatever else is
> > happening to cause the #pragma once issue so it is consistent with what
> > Apple is doing when they just copy the headers.
> 
> Copying headers is fundamentally incompatible with #pragma once.
> 
> The real question here is: why does Apple Windows build at all? I would
> expect it to be broken too.

Not everything is using #pragma once. See https://bugs.webkit.org/show_bug.cgi?id=174986 where some wtf headers aren't working. Then there's https://bugs.webkit.org/show_bug.cgi?id=177202. These are all fundamentally the same bug.

If you want to get an idea on what is and isn't using #pragma once https://github.com/cgmb/guardonce is a nice python utility.

Its my understanding that Apple has a HARD requirement that each library be able to be built independently. There is also the requirement that if a library can be built as a framework then the headers need to be flat, eg #include <WebCore/Foo.h>. That is the only reason pal and wtf are not flat since they're built statically.

Internally we've been looking at how to solve this with copying for all CMake ports. We don't have anything completed yet but we are hitting the same issue Mark is hitting with WebKit(2) support on WinCairo.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20171117/d8eb4b27/attachment.html>


More information about the webkit-unassigned mailing list