Export all CWV* symbols from the ios/web_view dynamic library.

ios/web_view/public/cwv.h

 // Copyright 2014 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #ifndef IOS_WEB_VIEW_PUBLIC_CWV_H_
 #define IOS_WEB_VIEW_PUBLIC_CWV_H_
 
 #import <CoreGraphics/CoreGraphics.h>
 #import <Foundation/Foundation.h>
 
+#include "cwv_export.h"

[Hiroshi Ichikawa, 2017/03/22 09:44:24]

Can you advise me if this relative include is appropriate here? I know that
absolute includes are usually used in Chromium, but absolute includes won't work
in client code of the dynamic framework.

[Eugene But (OOO till 7-30), 2017/03/22 15:18:54]

This relative include may not work for clients who are going to include this
framework header. For all public headers we should probably use framework style
includes with angle braces.

[michaeldo, 2017/03/22 23:16:22]

I don't think we should have this here as-is. Maybe it's possible to use a
define of some sort within ios/web_view/BUILD.gn in the
ios_framework_bundle("web_view") section and if it is building the framework,
include it like #include <ChromeWebView/cwv_export.h> otherwise, include it with
absolute path. I'm not positive this will work, but may be worth trying.

[Hiroshi Ichikawa, 2017/03/23 05:03:02]

Thanks, I tried it and it looks working. It looks a bit silly that we need to
write 5 lines of code everywhere to include cwv_export.h which essentially is
just 5 lines, though. 

Alternative idea is to directly embed the contents of cwv_export.h to all files.
But I slightly prefer the current structure because we probably don't want to
copy the comments in cwv_export.h to all files as well.

Another issue I found is that source code inside //ios/web_view/shell only
accepts absolute path include, not in the form of #include <ChromeWebView/...h>.
Is it as expected, or should it accept #include <ChromeWebView/...h>? I defined
CWV_IMPLEMENTATION in //ios/web_view/shell/BUILD.gn as a workaround for now.
I thought that #include "..." usually searches for the file in the same
directory too. But isn't it always the case?

[michaeldo, 2017/03/23 15:12:41]

I'm not sure if it will always search current directory, I suppose there are
both style reasons and functional reasons for using full path includes. I think
this solution is OK, but I'd like to hear what Eugene thinks as well.

I agree we shouldn't duplicate the same code in all the headers. I wonder if it
is reasonable to only use the framework style include as we currently only build
the framework and it's likely that no other code in Chromium code base should
depend on pieces of ios/web_view without depending on the build framework
directly. This would let us simplify this code and prevent unexpected
dependancies on ios/web_view.

I will look into why shell doesn't allow those includes. Maybe it's dependency
on this lib is not connected correctly.

[Hiroshi Ichikawa, 2017/03/24 04:57:42]

Do you mean that
#include <ChromeWebView/cwv_export.h>
should work while building the framework?

Currently it doesn't work, causing this error:

In file included from ../../ios/web_view/internal/cwv.mm:5:
../../ios/web_view/public/cwv.h:14:10: fatal error: 'ChromeWebView/cwv_export.h'
file not found

+
 @protocol CWVDelegate;
 @class CWVWebView;
 
 // Main interface for the CWV library.
-__attribute__((visibility("default"))) @interface CWV : NSObject
+CWV_EXPORT @interface CWV : NSObject

[Hiroshi Ichikawa, 2017/03/22 09:44:24]

I found that this token (or even __attribute__((visibility("default"))))
confuses git cl format and let it format the line in a weird way. Do you know of
any workaround?

[Eugene But (OOO till 7-30), 2017/03/22 15:18:54]

I don't know about workarounds, but you can file a bug agains clang-format.

[Hiroshi Ichikawa, 2017/03/23 05:03:02]

Do you know where to file a bug? Do we use the one provided by Clang?:
https://clang.llvm.org/docs/ClangFormat.html

It's not critical because I can fix it manually after running clang-format,
though. It looks also tricky to format it correctly, which requires to know that
CWV_EXPORT is a macro which works as an annotation for @interface.

[michaeldo, 2017/03/23 15:12:41]

Just a heads up that fixing it manually isn't ideal because if someone else
touches the file, they will likely not manually fix a strange format (and this
is ok and expected actually).

How is it formatting CWV_EXPORT?

[Hiroshi Ichikawa, 2017/03/24 04:57:42]

I agree that fixing manually every time is annoying.

I found that format won't be broken if I break the line after CWV_EXPORT, so
updated in that way. How does it look? I'm not sure if it's preferred to break
the line after CWV_EXPORT anyway (I believe it's not covered by the style
guide).

This is the current format by "git cl format" without breaking the line after
CWV_EXPORT:


// Main interface for the CWV library.
CWV_EXPORT @interface CWV
    : NSObject

      // Initializes the CWV library. This function should be called from
      // |application:didFinishLaunchingWithOptions:|.
      +
      (void)configureWithDelegate : (id<CWVDelegate>)delegate;

// Shuts down the CWV library.  This function should be called from
// |applicationwillTerminate:|.
+ (void)shutDown;

// Creates and returns a web view.
+ (CWVWebView*)webViewWithFrame:(CGRect)frame;

@end

 
 // Initializes the CWV library. This function should be called from
 // |application:didFinishLaunchingWithOptions:|.
 + (void)configureWithDelegate:(id<CWVDelegate>)delegate;
 
 // Shuts down the CWV library.  This function should be called from
 // |applicationwillTerminate:|.
 + (void)shutDown;
 
 // Creates and returns a web view.
 + (CWVWebView*)webViewWithFrame:(CGRect)frame;
 
 @end
 
 #endif  // IOS_WEB_VIEW_PUBLIC_CWV_H_