Add CONTENT_EXPORT_PRIVATE macro

Add CONTENT_EXPORT_PRIVATE macro

In contrast to CONTENT_EXPORT which exports symbols to embedders,
CONTENT_EXPORT_PRIVATE is intended to allow unit tests to access features
not meant to be used directly by real embedders.

BUG=136495
TEST=none

[jochen (gone - plz use gerrit), 2012-07-10 09:57:41]

plz review

[jam, 2012-07-10 16:01:26]

I didn't think the chromium-dev thread on this topic had reached a conclusion
about whether we should use a separate macro or not for tests?

Either way though, I'm not sure this is necessary for content since it already
has a well defined api in content/public. net/base don't have such directories,
so I can see why it might be useful there.

[jochen (gone - plz use gerrit), 2012-07-10 18:12:25]

On 2012/07/10 16:01:26, John Abd-El-Malek wrote:
> I didn't think the chromium-dev thread on this topic had reached a conclusion
> about whether we should use a separate macro or not for tests?

At least our documentation says you should do like net:
http://www.chromium.org/developers/how-tos/component-build

> 
> Either way though, I'm not sure this is necessary for content since it already
> has a well defined api in content/public. net/base don't have such
directories,
> so I can see why it might be useful there.


I think it's a bit unfortunate that the CONTENT_EXPORT macro is used outside of
content/public - actually, given that all content API should be in
content/public, it feels wrong to need such a macro at all.

[jam, 2012-07-10 20:39:55]

On 2012/07/10 18:12:25, jochen wrote:
> On 2012/07/10 16:01:26, John Abd-El-Malek wrote:
> > I didn't think the chromium-dev thread on this topic had reached a
conclusion
> > about whether we should use a separate macro or not for tests?
> 
> At least our documentation says you should do like net:
> http://www.chromium.org/developers/how-tos/component-build

yeah, I saw that wiki. unfortunately our wikis and email threads aren't always
the same. the chromium dev thread didn't seem to reach any consensus

the wiki also says "The current solution is to have multiple definition of the
export macros, so that at least someone reading the code will see that a given
class or method is exported for the unit tests and not because it is intended to
be used by consumers. See for example src/net/base/net_export.h"

i.e. it's trying to solve a problem that doesn't exist here

> 
> > 
> > Either way though, I'm not sure this is necessary for content since it
already
> > has a well defined api in content/public. net/base don't have such
> directories,
> > so I can see why it might be useful there.
> 
> 
> I think it's a bit unfortunate that the CONTENT_EXPORT macro is used outside
of
> content/public - actually, given that all content API should be in
> content/public, it feels wrong to need such a macro at all.

what about unittests inside content? not exporting symbols would mean not using
component build for the unittest targets, which would be slower

[jochen (gone - plz use gerrit), 2012-07-11 17:44:27]

On 2012/07/10 20:39:55, John Abd-El-Malek wrote:
> > 
> > I think it's a bit unfortunate that the CONTENT_EXPORT macro is used outside
> of
> > content/public - actually, given that all content API should be in
> > content/public, it feels wrong to need such a macro at all.
> 
> what about unittests inside content? not exporting symbols would mean not
using
> component build for the unittest targets, which would be slower

I think what I meant to say was that we shouldn't have CONTENT_EXPORT at all,
but just export all symbols defined in headers in content/public. We'd only use
the macro for stuff for testing then. Right now, it seems like we have to mark
everything in the API twice.

Not sure whether that's possible.

I guess it's no big deal either way. So in case you prefer to use CONTENT_EXPORT
everywhere, that's fine with me