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.
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 <annu...@yandex.ru> wrote: > > > > 30.03.2016, 19:47, "Brent Fulgham" <bfulg...@apple.com > <mailto:bfulg...@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 <aproskurya...@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 <bfulg...@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 <bfulg...@apple.com> wrote: >>>>> >>>>> Looking now. >>>>> >>>>> -Brent >>>>> >>>>>> On Mar 30, 2016, at 9:02 AM, Darin Adler <da...@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@lists.webkit.org >>>>>> https://lists.webkit.org/mailman/listinfo/webkit-dev >>>>> >>>>> _______________________________________________ >>>>> webkit-dev mailing list >>>>> webkit-dev@lists.webkit.org >>>>> https://lists.webkit.org/mailman/listinfo/webkit-dev >>>> >>>> _______________________________________________ >>>> webkit-dev mailing list >>>> webkit-dev@lists.webkit.org >>>> https://lists.webkit.org/mailman/listinfo/webkit-dev >> >> _______________________________________________ >> webkit-dev mailing list >> webkit-dev@lists.webkit.org >> https://lists.webkit.org/mailman/listinfo/webkit-dev > > -- > Regards, > Konstantin > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org> > https://lists.webkit.org/mailman/listinfo/webkit-dev > <https://lists.webkit.org/mailman/listinfo/webkit-dev>
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
