Dart: Removes all but native calls and the handle watcher from the snapshot.

Dart: Removes all but native calls and the handle watcher from the snapshot.

The bindings, core, and application libraries are now referred to as, e.g.:

package:mojo/public/dart/core.dart

Since the handle watcher remains in the snapshot, it no
longer refers to types defined in core.dart. References to types defined
in core.dart are also removed from mojo_natives.cc.

In Dart packaged apps, the SDK is zipped up under mojo/public/dart.

For embedder tests, the SDK is copied into the generated source output directory.

A base_dir parameter is added to the 'dart_package' and 'mojom' GN macros so that
consumers of the Mojo SDK can all import using the same URIs regardless of where
the SDK lives in their source trees.

BUG=
R=erg@chromium.org

Committed: https://chromium.googlesource.com/external/mojo/+/92c2402531955da1f48a18c986f24aa21a50cc77

[zra, 2015-03-20 21:56:24]

zra@google.com changed reviewers:
+ abarth@chromium.org, erg@chromium.org

[zra, 2015-03-20 21:56:25]

This is the refactoring we discussed on Wednesday. There are lots of files, but
it is mostly just renaming dart:mojo.X -> package:mojo/public/dart/X.dart.

@erg: This should go cleanly into Modular with the above change as well as
renaming package:third_party/mojo/src/mojo/... -> package:mojo/..., which should
just be the application mojoms, unless I have missed something.

@johnmccutchan: Can you scope out how disruptive this will be to landing your io
changes?

Thanks!

https://codereview.chromium.org/1027603002/diff/80001/mojo/dart/embedder/mojo...
File mojo/dart/embedder/mojo_natives.cc (left):

https://codereview.chromium.org/1027603002/diff/80001/mojo/dart/embedder/mojo...
mojo/dart/embedder/mojo_natives.cc:95: Dart_Handle core_lib_name =
Dart_NewStringFromCString("dart:mojo.core");
This library is no longer in the snapshot.

https://codereview.chromium.org/1027603002/diff/80001/mojo/dart/embedder/mojo...
mojo/dart/embedder/mojo_natives.cc:225: MojoLib(),
Dart_NewStringFromCString("MojoHandleSignalsState"));
Instead of making an instance of the State class from core.dart, we'll just
return a list.

[Elliot Glaysher, 2015-03-20 22:16:03]

https://codereview.chromium.org/1027603002/diff/100001/examples/dart/console_...
File examples/dart/console_example/BUILD.gn (right):

https://codereview.chromium.org/1027603002/diff/100001/examples/dart/console_...
examples/dart/console_example/BUILD.gn:13:
"//mojo/public/interfaces/application",
console_example doesn't use //mojo/public/interfaces/application directly, yet
it needs to be in the final deps list. This seems error prone.

And yet, this might be the only way to get this to work. (I assume that if
//mojo/public/dart depends on //mojo/public/interfaces/application, the
autogenerated *.mojom.dart code gets rolled into the //mojo/public/dart dartzip
package. That's fine if the application doesn't reference application.mojom.dart
or friends, but becomes a collision if both targets are included...)

[zra, 2015-03-20 23:00:46]

https://codereview.chromium.org/1027603002/diff/100001/examples/dart/console_...
File examples/dart/console_example/BUILD.gn (right):

https://codereview.chromium.org/1027603002/diff/100001/examples/dart/console_...
examples/dart/console_example/BUILD.gn:13:
"//mojo/public/interfaces/application",
On 2015/03/20 22:16:02, Elliot Glaysher wrote:
> console_example doesn't use //mojo/public/interfaces/application directly, yet
> it needs to be in the final deps list. This seems error prone.
> 
> And yet, this might be the only way to get this to work. (I assume that if
> //mojo/public/dart depends on //mojo/public/interfaces/application, the
> autogenerated *.mojom.dart code gets rolled into the //mojo/public/dart
dartzip
> package. That's fine if the application doesn't reference
application.mojom.dart
> or friends, but becomes a collision if both targets are included...)

Adding a dependence on //mojo/public/interface/application to //mojo/public/dart
makes sense to me. There isn't a collision if both //mojo/public/dart and the
dart_pacakged_application depend on //mojo/public/interface/application.

[zra, 2015-03-20 23:05:14]

+johnmccutchan

Forgot to CC

[Elliot Glaysher, 2015-03-20 23:05:41]

https://codereview.chromium.org/1027603002/diff/100001/examples/dart/console_...
File examples/dart/console_example/BUILD.gn (right):

https://codereview.chromium.org/1027603002/diff/100001/examples/dart/console_...
examples/dart/console_example/BUILD.gn:13:
"//mojo/public/interfaces/application",
On 2015/03/20 23:00:46, zra wrote:
> On 2015/03/20 22:16:02, Elliot Glaysher wrote:
> > console_example doesn't use //mojo/public/interfaces/application directly,
yet
> > it needs to be in the final deps list. This seems error prone.
> > 
> > And yet, this might be the only way to get this to work. (I assume that if
> > //mojo/public/dart depends on //mojo/public/interfaces/application, the
> > autogenerated *.mojom.dart code gets rolled into the //mojo/public/dart
> dartzip
> > package. That's fine if the application doesn't reference
> application.mojom.dart
> > or friends, but becomes a collision if both targets are included...)
> 
> Adding a dependence on //mojo/public/interface/application to
//mojo/public/dart
> makes sense to me. There isn't a collision if both //mojo/public/dart and the
> dart_pacakged_application depend on //mojo/public/interface/application.

I am not entirely sure that that is how it works.

If you look at the dart_package() template in rules.gni, it takes its deps,
looks for a <name>.dartzip file, and the squashes that into its output.

So if you have //mojo/public/dart depend on //mojo/public/interface/application,
you have one resulting dart.dartzip file which contains the code from both
targets.

If you then have something depend on //mojo/public/dart and
//mojo/public/interface/application, you are now depending on two dartzip files
which define the same file. I don't know what the outcome of that is, if we
handle it gracefully, or what.

[zra, 2015-03-23 14:27:40]

https://codereview.chromium.org/1027603002/diff/100001/examples/dart/console_...
File examples/dart/console_example/BUILD.gn (right):

https://codereview.chromium.org/1027603002/diff/100001/examples/dart/console_...
examples/dart/console_example/BUILD.gn:13:
"//mojo/public/interfaces/application",
On 2015/03/20 23:05:40, Elliot Glaysher wrote:
> On 2015/03/20 23:00:46, zra wrote:
> > On 2015/03/20 22:16:02, Elliot Glaysher wrote:
> > > console_example doesn't use //mojo/public/interfaces/application directly,
> yet
> > > it needs to be in the final deps list. This seems error prone.
> > > 
> > > And yet, this might be the only way to get this to work. (I assume that if
> > > //mojo/public/dart depends on //mojo/public/interfaces/application, the
> > > autogenerated *.mojom.dart code gets rolled into the //mojo/public/dart
> > dartzip
> > > package. That's fine if the application doesn't reference
> > application.mojom.dart
> > > or friends, but becomes a collision if both targets are included...)
> > 
> > Adding a dependence on //mojo/public/interface/application to
> //mojo/public/dart
> > makes sense to me. There isn't a collision if both //mojo/public/dart and
the
> > dart_pacakged_application depend on //mojo/public/interface/application.
> 
> I am not entirely sure that that is how it works.
> 
> If you look at the dart_package() template in rules.gni, it takes its deps,
> looks for a <name>.dartzip file, and the squashes that into its output.
> 
> So if you have //mojo/public/dart depend on
//mojo/public/interface/application,
> you have one resulting dart.dartzip file which contains the code from both
> targets.
> 
> If you then have something depend on //mojo/public/dart and
> //mojo/public/interface/application, you are now depending on two dartzip
files
> which define the same file. I don't know what the outcome of that is, if we
> handle it gracefully, or what.

Looking at DoZip in //mojo/public/tools/gn/zip.py, if a file name exists in
|inputs|, entries for the same file name in |zip_inputs| are ignored. Likewise,
if a file name is included from two entries of |zip_inputs| it will be included
only from the first one.

So, in this case, the file will come from //mojo/public/dart. Since the
application mojoms are the same file for //mojo/public/dart and
//mojo/public/interface/application, it doesn't actually matter which comes
first, though.

[Elliot Glaysher, 2015-03-23 17:43:17]

lgtm then

(I still feel like that should be analogous to a duplicate symbol error or
something; but if its not going to break the build, then whatever.)

[zra, 2015-03-23 18:00:58]

On 2015/03/23 17:43:17, Elliot Glaysher wrote:
> lgtm then
> 
> (I still feel like that should be analogous to a duplicate symbol error or
> something; but if its not going to break the build, then whatever.)

Thanks. After landing this, I'll try to add an error like that in zip.py to see
what happens.

[zra, 2015-03-23 18:04:09]

Committed patchset #8 (id:120001) manually as
92c2402531955da1f48a18c986f24aa21a50cc77 (presubmit successful).