Make more services' public interfaces flexible wrt location in repo.

Make more services' public interfaces flexible wrt location in repo.

This CL introduces a new pattern for making services' public interfaces
flexible wrt location in the repo. A mojom target can now add import_dirs.
Each service target adds an import dir of the parent directory of
"<service>/public" and specifies its imports relative to that directory.
This CL covers the interfaces for geometry, gpu, input_events, and
native_viewport.

R=jamesr@chromium.org

Committed: https://chromium.googlesource.com/external/mojo/+/47580b78677179f8138f6a848abad2cd2d6560b1

[blundell, 2015-01-07 21:58:44]

blundell@chromium.org changed reviewers:
+ jamesr@chromium.org

[jamesr, 2015-01-08 19:07:46]

https://codereview.chromium.org/839903002/diff/1/mojo/services/gpu/public/int...
File mojo/services/gpu/public/interfaces/gpu.mojom (right):

https://codereview.chromium.org/839903002/diff/1/mojo/services/gpu/public/int...
mojo/services/gpu/public/interfaces/gpu.mojom:7: import
"../../../geometry/public/interfaces/geometry.mojom";
this is really weird.  It sorta makes sense for some cases like C++ where we're
pretty constrained by existing code and setups, but for mojom I think we can try
to do better

what about having mojom targets declare their paths relative to some root (i.e.
mojo/services/gpu/public/interfaces/ can have all of its paths be relative to
//mojo/services) and export that in the public_configs of the mojom template?
Then if you use public_deps correctly (which you should anyway) then you get
include paths from things you declare dependencies on and can write imports like
this:

import "geometry/public/interfaces/geometry.mojom";
import "gpu/public/interfaces/gpu.mojom";

etc


in practice with the //mojo/services/XXX/public family this means they'll all
add //mojo/services to the mojom include path, but if these move then they'll
still work

[blundell, 2015-01-09 10:08:07]

https://codereview.chromium.org/839903002/diff/1/mojo/services/gpu/public/int...
File mojo/services/gpu/public/interfaces/gpu.mojom (right):

https://codereview.chromium.org/839903002/diff/1/mojo/services/gpu/public/int...
mojo/services/gpu/public/interfaces/gpu.mojom:7: import
"../../../geometry/public/interfaces/geometry.mojom";
On 2015/01/08 19:07:46, jamesr wrote:
> this is really weird.  It sorta makes sense for some cases like C++ where
we're
> pretty constrained by existing code and setups, but for mojom I think we can
try
> to do better
> 
> what about having mojom targets declare their paths relative to some root
(i.e.
> mojo/services/gpu/public/interfaces/ can have all of its paths be relative to
> //mojo/services) and export that in the public_configs of the mojom template?
> Then if you use public_deps correctly (which you should anyway) then you get
> include paths from things you declare dependencies on and can write imports
like
> this:
> 
> import "geometry/public/interfaces/geometry.mojom";
> import "gpu/public/interfaces/gpu.mojom";
> 
> etc
> 
> 
> in practice with the //mojo/services/XXX/public family this means they'll all
> add //mojo/services to the mojom include path, but if these move then they'll
> still work

If I understand what you're suggesting correctly, the mojom template would have
to be able to loop through all the "import_dirs" that are added to a given
target from its deps adding each one as a "-I" arg to the generator_script. I
don't think this is possible: AFAIK a target cannot see configs that are added
to it by its deps via public_configs (cf. "gn help public_configs"). (There is
also a more minor problem that a config can only set a restricted set of
variables, so these "import_dirs" would have to be specified as include_dirs,
which seems icky to me as it is conflating include paths at the mojom level and
the C++ level).

[jamesr, 2015-01-12 21:32:48]

I think include_dirs in a mojom() target can have only one meaning (the -I param
to the generator) since mojom files can only have import statements, so I think
using it would be appropriate.

[blundell, 2015-01-13 01:46:14]

Patchset #3 (id:40001) has been deleted

[blundell, 2015-01-13 01:54:06]

Patchset #3 (id:60001) has been deleted

[blundell, 2015-01-13 02:02:23]

As discussed offline, it's not possible to get at the public configs and loop
over them to add their include_dirs in mojom.gni. This CL now adds an
import_dirs var that mojom targets can use to specify the import paths that they
and their dependents require.

[jamesr, 2015-01-14 21:30:36]

lgtm

[blundell, 2015-01-14 23:26:00]

Committed patchset #3 (id:80001) manually as
47580b78677179f8138f6a848abad2cd2d6560b1 (presubmit successful).