[GTK][WPE] Fix non-unified builds after r250857

[Adrian Perez]

I am preparing another of my bi-weekly cleanups to keep the
build green with unified builds disabled :-}

[Adrian Perez]

Created attachment 381285 [details]
Patch

[Adrian Perez]

I'll make sure that the normal (unified) build run by the
EWS and the bots won't be broken before landing this 👍

[Adrian Perez]

(In reply to Adrian Perez from comment #2)
> I'll make sure that the normal (unified) build run by the
> EWS and the bots won't be broken before landing this 👍

Marking WebCore/Modules/async-clipboard/ClipboardItemPasteboardDataSource.cpp
as @no-unify fixes the issue.

It looks like otherwise e.g. both ForwardingHeaders/WebCore/Exception.h
and WebCore/dom/Exception.h are included which causes re-definitions of
types. I'll poke a bit more at it in case I can come up with a better
solution.

[Tim Horton]

Comment on attachment 381285 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=381285&action=review

> Source/WebCore/ChangeLog:3
> +        [GTK][WPE] Fix non-unified builds after r250857

Do you have an easy way to do a non unified build? This would probably help some of my build time efforts too (at least accelerate getting to a green patch)

> Source/WebCore/Modules/async-clipboard/ClipboardItemPasteboardDataSource.cpp:29
> +#include <WebCore/JSDOMPromiseDeferred.h>

These are in the wrong order

[Adrian Perez]

(In reply to Tim Horton from comment #4)
> Comment on attachment 381285 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=381285&action=review
> 
> > Source/WebCore/ChangeLog:3
> > +        [GTK][WPE] Fix non-unified builds after r250857
> 
> Do you have an easy way to do a non unified build? This would probably help
> some of my build time efforts too (at least accelerate getting to a green
> patch)

For the CMake ports it's enough to pass -DENABLE_UNIFIED_BUILDS=OFF
when configuring the build. With the “build-webkit” script that
would be:

  % build-webkit --gtk --cmakeargs=-DENABLE_UNIFIED_BUILDS=OFF

(I don't know how to achieve the same with Xcode, sorry about that)

> > Source/WebCore/Modules/async-clipboard/ClipboardItemPasteboardDataSource.cpp:29
> > +#include <WebCore/JSDOMPromiseDeferred.h>
> 
> These are in the wrong order

Yes, I'll reorder them. Somehow “check-webkit-style” did not catch
it—I think it's not taking into account the angle brackets and double
quote characters for sorting them, maybe. Thanks for pointing this out!

[Adrian Perez]

This also needs a rebase after r251279 was landed.

[Adrian Perez]

(In reply to Adrian Perez from comment #3)
> (In reply to Adrian Perez from comment #2)
> > I'll make sure that the normal (unified) build run by the
> > EWS and the bots won't be broken before landing this 👍
> 
> Marking WebCore/Modules/async-clipboard/ClipboardItemPasteboardDataSource.cpp
> as @no-unify fixes the issue.
> 
> It looks like otherwise e.g. both ForwardingHeaders/WebCore/Exception.h
> and WebCore/dom/Exception.h are included which causes re-definitions of
> types. I'll poke a bit more at it in case I can come up with a better
> solution.

This is solved by using

  #include "JSDOMPromiseDeferred.h"

instead of 

  #include <WebCore/JSDOMPromiseDeferred.h>

(Of course!)

[Adrian Perez]

Created attachment 381372 [details]
Patch for landing

[WebKit Commit Bot]

Comment on attachment 381372 [details]
Patch for landing

Clearing flags on attachment: 381372

Committed r251326: <https://trac.webkit.org/changeset/251326>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Radar WebKit Bug Importer]

<rdar://problem/56437096>