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

[bugzilla-daemon at webkit.org]

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

--- Comment #27 from Mark Salisbury <mark.salisbury at hp.com> ---
I believe that both Windows ports (AppleWin, WinCairo) have the same xcopy logic to create forwarding headers.

Source\JavaScriptCore\PlatformWin.cmake is used by both CMake builds.

The copy was introduced here:
https://bugs.webkit.org/show_bug.cgi?id=148198

"CMake Windows build should not include files directly from other Source direc..."

At that time I don't think #pragma once was being used.

The rationale was as has been mentioned so that the next projects (frameworks) could include previous frameworks with a simple #include <JavaScriptCore/SomeJSFile.h>.

There's no careful selection of what public .h files should be, and it'd be hard to do so anyway since one .h file can lead to many others, sometimes ones you don't expect.

So here's where I am with this now.  My current patch has an incompatibility with WebKit/Scripts/generate-forwarding-headers.pl.  They both try to create forwarding headers for some of the same JavaScriptCore files.  I print the full path to the .h file and WebKit/Scripts/generate-forwarding-headers.pl lists out a relative path.  WebKit/Scripts/generate-forwarding-headers.pl overwrites that path that the script in this patch products.

The reason I went with the full path is that I saw a problem with infinite recursion of a forwarding header include.  The forwarding header include path came before the real directory, so once an include started on a forwarding header, it tried to include the exact same file again.  A #pragma once in the forwarding header would prevent the re-inclusion, however, it would also fail to include the real .h file.

The infinite recursion to me means that there is some ordering difference in header search paths between my build and WinCairo build.

I see a couple of options, if I am to pursue preventing copying of .h files (which I hope others agree fundamentally doesn't make sense):

1) Modify WebKit/Scripts/generate-forwarding-headers.pl so that it prints the full path to the real header.  Then the order of header search paths doesn't matter.  This does make the derived sources output (forwarding headers) not relocatable.  I don't know if it needs to be.  I believe these .h files are just used in an internal build.  The real public .h files from WebKit are JavaScriptCore API and WebKit API files.

2) Figure out why my Win WPE build has a different header search path order than WinCairo.  The forwarding header include path has to come AFTER the include search path that triggers finding the real .h file.  In practice I think that means the forwarding header path should come last.

Thoughts?

Thanks everyone.  I've been a downstream user of WebKit for quite a while now and feel bad that I haven't been able to give back more.  I'm hoping to be a better citizen as we are now working on updating our WebKit version (used in HP products).

-- 
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/20171118/a62e1e9d/attachment.html>