Remove CWV_IMPLEMENTATION hack.

Remove CWV_IMPLEMENTATION hack.

BUG=704946
Review-Url: https://codereview.chromium.org/2782253002
Cr-Commit-Position: refs/heads/master@{#460713}
Committed: https://chromium.googlesource.com/chromium/src/+/5d8ebc9543e8def157337ed491463c55fd45c785

[michaeldo, 2017-03-29 17:23:04]

michaeldo@chromium.org changed reviewers:
+ sdefresne@chromium.org

[sdefresne, 2017-03-29 18:02:33]

Can you send to the try bots?

[michaeldo, 2017-03-29 18:25:26]

The CQ bit was checked by michaeldo@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-03-29 18:26:15]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-29 19:00:18]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-03-29 19:00:18]

Dry run: This issue passed the CQ dry run.

[michaeldo, 2017-03-29 20:21:35]

On 2017/03/29 18:02:33, sdefresne wrote:
> Can you send to the try bots?

Looks like try bots are good. PTAL.

[sdefresne, 2017-03-30 09:44:22]

The CQ bit was checked by sdefresne@chromium.org

[sdefresne, 2017-03-30 09:44:23]

lgtm

[commit-bot: I haz the power, 2017-03-30 09:44:36]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-30 09:49:45]

CQ is committing da patch.

Bot data: {"patchset_id": 1, "attempt_start_ts": 1490867062785500, "parent_rev":
"b0aa350005eb462f10491cd574ec18805247bfdb", "commit_rev":
"5d8ebc9543e8def157337ed491463c55fd45c785"}

[commit-bot: I haz the power, 2017-03-30 09:50:37]

Description was changed from

==========
Remove CWV_IMPLEMENTATION hack.

BUG=704946
==========

to

==========
Remove CWV_IMPLEMENTATION hack.

BUG=704946

Review-Url: https://codereview.chromium.org/2782253002
Cr-Commit-Position: refs/heads/master@{#460713}
Committed:
https://chromium.googlesource.com/chromium/src/+/5d8ebc9543e8def157337ed49146...
==========

[commit-bot: I haz the power, 2017-03-30 09:50:38]

Committed patchset #1 (id:1) as
https://chromium.googlesource.com/chromium/src/+/5d8ebc9543e8def157337ed49146...

[Hiroshi Ichikawa, 2017-03-31 06:48:30]

ichikawa@chromium.org changed reviewers:
+ ichikawa@chromium.org

[Hiroshi Ichikawa, 2017-03-31 06:48:31]

https://codereview.chromium.org/2782253002/diff/1/ios/web_view/public/cwv.h
File ios/web_view/public/cwv.h (right):

https://codereview.chromium.org/2782253002/diff/1/ios/web_view/public/cwv.h#n...
ios/web_view/public/cwv.h:11: #include "cwv_export.h"
I'm a bit confused with this CL. Didn't we originally want to avoid this kind of
relative #include?

[michaeldo, 2017-03-31 15:18:17]

On 2017/03/31 06:48:31, Hiroshi Ichikawa wrote:
> https://codereview.chromium.org/2782253002/diff/1/ios/web_view/public/cwv.h
> File ios/web_view/public/cwv.h (right):
> 
>
https://codereview.chromium.org/2782253002/diff/1/ios/web_view/public/cwv.h#n...
> ios/web_view/public/cwv.h:11: #include "cwv_export.h"
> I'm a bit confused with this CL. Didn't we originally want to avoid this kind
of
> relative #include?

I'm sorry Hiroshi, you're right. I just went back and read our conversation
here:
https://codereview.chromium.org/2770633002/diff/1/ios/web_view/public/cwv.h. I
was looking into this and then noticed sdefresne's CL here:
https://codereview.chromium.org/2782823004/ and found it would work if
simplified a bit without the gn changes. However, I was focused on simplifying
the changes needed to get the include to work and hadn't recalled our lengthy
discussion about this that lead to the header include hack in the first place. I
have reverted this change (in a new CL since here some of these includes were
just added not switched to relative includes) for all the reasons we initially
discussed. Sorry again for the confusion.

sdefresne@, is there any way we can get gn to understand a framework style
include in the public headers instead of relative or absolute includes?

[sdefresne, 2017-04-03 13:22:44]

On 2017/03/31 15:18:17, michaeldo wrote:
> On 2017/03/31 06:48:31, Hiroshi Ichikawa wrote:
> > https://codereview.chromium.org/2782253002/diff/1/ios/web_view/public/cwv.h
> > File ios/web_view/public/cwv.h (right):
> > 
> >
>
https://codereview.chromium.org/2782253002/diff/1/ios/web_view/public/cwv.h#n...
> > ios/web_view/public/cwv.h:11: #include "cwv_export.h"
> > I'm a bit confused with this CL. Didn't we originally want to avoid this
kind
> of
> > relative #include?
> 
> I'm sorry Hiroshi, you're right. I just went back and read our conversation
> here:
> https://codereview.chromium.org/2770633002/diff/1/ios/web_view/public/cwv.h. I
> was looking into this and then noticed sdefresne's CL here:
> https://codereview.chromium.org/2782823004/ and found it would work if
> simplified a bit without the gn changes. However, I was focused on simplifying
> the changes needed to get the include to work and hadn't recalled our lengthy
> discussion about this that lead to the header include hack in the first place.
I
> have reverted this change (in a new CL since here some of these includes were
> just added not switched to relative includes) for all the reasons we initially
> discussed. Sorry again for the confusion.
> 
> sdefresne@, is there any way we can get gn to understand a framework style
> include in the public headers instead of relative or absolute includes?

Yes, this is what my CL did (it uses relative imports for cwv_export.h but could
instead use <ChromeWebView/cwv_export.h>).