[webkit-dev] Is someone going to fix Windows EWS?

Wed Mar 30 11:19:17 PDT 2016

30.03.2016, 20:41, "Alex Christensen" <achristensen at apple.com>:
> I agree that it would be better to have one approach to copying forwarding headers, but there is a fundamental disagreement between the needs of the ports.  Windows needs the entire header to be copied into the forwarding directory because some internal builds are built without the other directories existing, such as JavaScriptCore being built without WTF being right next to it.  This will not change.  Linux ports want everything to be fast and automatic, so their forwarding headers are just a small file that #includes the relative path to the file being included.

I can see the following solution:

1. generate-forwarding-headers.pl could be trivially modified to copy entire header on Windows (or a bit less trivially to change mode via command line option)

Another option is to use hard links everywhere, though it may cause troubles for Haiku folks.

2. If your internal build requires copying headers ahead of time without knowing which of them will be used in the latter builds of different subprojects, xcopy post-build command could be kept, but not executed in regular builds.

>
> Yesterday was a rough day for the CMake ports because I made WebCore more than one static library.  I think I know what’s wrong with the headers in clean builds and I’ll fix it soon.
>> On Mar 30, 2016, at 10:06 AM, Konstantin Tokarev <annulen at yandex.ru> wrote:
>>
>> 30.03.2016, 19:47, "Brent Fulgham" <bfulgham at apple.com>:
>>> This is happening because “Font.h” is referring to “<WebCore/CoreGraphicsSPI.h>”, which doesn’t always exist on Windows at the time the file is compiled. The CoreGraphicsSPI.h file lives in “WebCore/platform/spi/cg/CoreGraphicsSPI.h”, and can be found with a normal ‘#include “CoreGraphicsSPI.h”. It’s only after a post-build step copies the file to “DerivedSources/ForwardingHeaders/WebCore/CoreGraphicsSPI.h” that the ‘#include <WebCore/CoreGraphicsSPI.h>” form works.
>>>
>>> When a non-clean build is performed, this is fine, so EWS probably works properly most of the time. But if something prompts it to clean the build output, the file doesn’t exist and the build fails, improperly blaming the current patch.
>>>
>>> I’ll talk to Alex about the copy phase of these headers and see if we can get this into proper position earlier.
>>
>> Actually, for now we have 3 independent mechanisms of header copying with CMake build:
>>
>> 1. WEBKIT_CREATE_FORWARDING_HEADERS() CMake macro
>> 2. Custom pre- and post-build commands which invoke xcopy (obviously Windows-only)
>> 3. Script Source/WebKit2/Scripts/generate-forwarding-headers.pl which AFAIU looks into source files and determines which headers do actually need to be copied, than copies them.
>>
>> IMO it would be better to use one approach, and it looks like that generate-forwarding-headers.pl is the most powerful option.
>>
>>> Thanks,
>>>
>>> -Brent
>>>
>>>>  On Mar 30, 2016, at 9:28 AM, Alexey Proskuryakov <aproskuryakov at gmail.com> wrote:
>>>>
>>>>  They fail like this: https://webkit-queues.webkit.org/queue-status/win-ews/bots/ews202https://webkit-queues.webkit.org/results/1069527
>>>>
>>>>  c:\cygwin\home\buildbot\webkit\source\webcore\platform\graphics\Font.h(57): fatal error C1083: Cannot open include file: 'WebCore/CoreGraphicsSPI.h': No such file or directory (compiling source file C:\cygwin\home\buildbot\WebKit\Source\WebCore\DerivedSources.cpp) [C:\cygwin\home\buildbot\WebKit\WebKitBuild\Release\Source\WebCore\WebCoreDerivedSources.vcxproj]
>>>>
>>>>  It's quite surprising that the build passes after rolling out a patch, thus making EWS think that the patch is to blame.
>>>>
>>>>  - Alexey
>>>>
>>>>>  30 марта 2016 г., в 9:20, Brent Fulgham <bfulgham at apple.com> написал(а):
>>>>>
>>>>>  Aside from ews206 being offline for some reason, all bot seem to be running without any errors.
>>>>>
>>>>>  Can you point me at a couple of the patches you were looking at? I spot-checked a couple in the Review Queue and they seemed to be failing for legitimate problems with the patches.
>>>>>
>>>>>  Thanks,
>>>>>
>>>>>  -Brent
>>>>>
>>>>>>  On Mar 30, 2016, at 9:04 AM, Brent Fulgham <bfulgham at apple.com> wrote:
>>>>>>
>>>>>>  Looking now.
>>>>>>
>>>>>>  -Brent
>>>>>>
>>>>>>>  On Mar 30, 2016, at 9:02 AM, Darin Adler <darin at apple.com> wrote:
>>>>>>>
>>>>>>>  Every patch I look at has a red bubble for Windows on EWS. Is someone planning on fixing this?
>>>>>>>
>>>>>>>  — Darin
>>>>>>>  _______________________________________________
>>>>>>>  webkit-dev mailing list
>>>>>>>  webkit-dev at lists.webkit.org
>>>>>>>  https://lists.webkit.org/mailman/listinfo/webkit-dev
>>>>>>
>>>>>>  _______________________________________________
>>>>>>  webkit-dev mailing list
>>>>>>  webkit-dev at lists.webkit.org
>>>>>>  https://lists.webkit.org/mailman/listinfo/webkit-dev
>>>>>
>>>>>  _______________________________________________
>>>>>  webkit-dev mailing list
>>>>>  webkit-dev at lists.webkit.org
>>>>>  https://lists.webkit.org/mailman/listinfo/webkit-dev
>>>
>>> _______________________________________________
>>> webkit-dev mailing list
>>> webkit-dev at lists.webkit.org
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>>
>> --
>> Regards,
>> Konstantin
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev

-- 
Regards,
Konstantin