Adding dart build

[laoshaw]

dart run will automatically do pub-get and compile and run, which is nice and similar to cargo-run or go-run.

dart compile exe -- needs to specify entry point and needs a separate pub-get step, tedious, but fine.

since dart-run respects pubspec.yaml and does what it needs to do, can we add dart build that also respects pubspec.yaml and auto builds some default output, e.g. exe, or multiple output, e.g. exe and aot, whatever is the most popular ones as the defaults?

this way the dart toolchain is also very consistent with others, e.g. rust and golang as mentioned above.

Thanks.

[dcharkes]

In the context of

• ☂️ [vm/ffi] Build hooks & Code assets #50565

I've prototyped some dart build functionality recently which outputs a folder, including possible dylibs from native packages: https://dart-review.googlesource.com/c/sdk/+/267340.

It would be worth considering other things than just native assets for a dart build.

[mit-mit]

dart compile exe -- needs to specify entry point and needs a separate pub-get step, tedious, but fine.

The "needs a separate pub-get step"-part is tracked here: #50422

[jakemac53]

Imo it would be better to not introduce another top level command which has a lot of overlap with an existing command. Can this be an option to compile like --bundle or something?

[mit-mit]

compile usually uses subcommand, so I'd think it should be dart compile bundle. wdyt Daco?

[jakemac53]

could bundle apply to both AOT and Kernel compilation? If so it should possibly be a flag for the subcommands?

[bkonyi]

I don't know how I feel about bundle covering all the build functionality since we're not necessarily creating a bundle of artifacts. We could just be compiling a library for use with FFI when we're running from source AFAIK. Maybe we could have dart compile bundle for preparing Dart applications to be shipped and dart compile native-libraries to just perform build steps needed for FFI artifacts?

[laoshaw]

build is consistent with other modern tools,e.g cargo,golang,please keep it

[dcharkes]

could bundle apply to both AOT and Kernel compilation?

Possibly, we would have a kernel file with dylibs next to it, and the kernel file containing the (relative) paths of the dylibs.
However, what would the use be? You can't really use that bundle without the dart SDK, and if you have a Dart SDK, why not run from source? So yes we could, but what is the product benefit?

If so it should possibly be a flag for the subcommands?

The commands currently take an optional output filename as parameter. That doesn't work with bundles, that parameter would need to be a directory. Adding a flag leading to a file/directory differents in output parameter and actual output might be surprising.

Maybe we could have dart compile bundle for preparing Dart applications to be shipped and dart compile native-libraries to just perform build steps needed for FFI artifacts?

How we build artifacts entirely depends on how we run. Dart doesn't have cross compilation (currently), so that's not on the table yet. But dart run and dart test will require all their native libraries to be dynamic libraries. While dart compile bundle (assuming AOT) can support both static and dynamic libraries. When we support static libraries, we can even do dart compile exe which would then build only static libaries and still output a single executable.

Therefore one would need to specify what to build when doing dart compile native-assets. For example dart compile native-assets -Dtarget=linux_x64 -Dpackaging=dynamic. (Side note, we've been using "native assets" as naming for the feature for a while. Not everything might be a "library".)

[dcharkes]

dart compile bundle

@mit-mit should that then be exe always? (and never aotsnapshot or kernel).

Otherwise it's going to be dart compile bundle exe.

[dcharkes]

Should we deprecate dart compile instead? Flutter is also flutter build? cc @mkustermann

(FWIW: flutter assemble is also a public command, though not used by users. If we care about consistency with Flutter.)