CONTENT_EXPORT only for unit tests?

[Alec Flett]

I have some tests that do unittests on some internal classes that happen to
be in content/browser/indexed_db

I'm getting linker errors (in the component build on linux) if I don't
include CONTENT_EXPORT on the relevant files, when building
content_unittests.

I'm trying not to bloat the content layer here - is there a way to only
export for tests?

Alec

[James Robinson]

That's what CONTENT_EXPORT is for.  To avoid bloating the public APIs, leave the symbol out of content/public/....  We don't have other distinctions for internal vs external exposure.

- James

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
 
 
 

[Fred Akalin]

Some other modules (net, sync, etc.) have foo_EXPORT and foo_EXPORT_PRIVATE, but it seems that content does not.

[Dirk Pranke]

Correct, we went through this debate at length when creating content, and the decision was the foo_EXPORT_PRIVATE was not something we wanted to encourage. We decided to grandfather in net and base (I think) because Ricardo had gone to great length to do that work already. There is also no practical difference between _EXPORT and _EXPORT_PRIVATE, as we don't currently have any code that enforces that _PRIVATE is only called from test files.

However, the reason we don't want to encourage _PRIVATE is that it does not provide any clues to the caller that you're calling a routine that is intended to be used only for testing. 

Better to use foo_EXPORT callXForTestPurposes() instead.

-- Dirk

[Alec Flett]

Ah! Had no idea. thanks..

Alec

On Tue, May 14, 2013 at 4:34 PM, James Robinson <jam...@google.com> wrote:

[Chris Bentzel]

One advantage of _PRIVATE is that you can annotate an entire class
that way - mentioning that the class is only being exported for
testing purposes. Right now comments are needed instead.

[Darin Fisher]

There's no need to comment when something is exported for testing purposes only.  Please don't worry about doing that.

We export functions to support the component build, which is meant only as a "maintainers build" of the system.  Gratuitous exports are OK.

For example, when you export an entire class, you also export all inline functions, making them non-inline.  We would not do that if we cared about shipping this config.

Use export macros liberally to make the component build easier to maintain.

Finally, separating public API from internal API is better done through more explicit conventions such as:
1- Put public API in a "public" folder (enforce usage with checkdeps),
2- Put internal API (sounds like an oxymoron, but this refers to private stuff that is visible in a public header) in an "internal" namespace,
3- Use "ForTesting" suffix on public methods made available only for testing.

-Darin