[native_assets_builder] If running hook/build.dart of a package fails, then we should not continue building dependent packages

[mkustermann]

It seems currently the build runner will make a plan (order of packages) and then build all of them. See here

  Future<HookResult> _run({}) async {
    ...
    final (buildPlan, packageGraph, planSuccess) = await _makePlan(...);
    ...
    for (final package in buildPlan) {
    ...
    final (hookOutput, packageSuccess) = await _runHookForPackageCached(...);
    final validateResult = validateNoDuplicateDylibs(hookResult.assets);
    if (validateResult.isNotEmpty) {
      for (final error in validateResult) {
        logger.severe(error);
      }
      hookResult = hookResult.copyAdd(HookOutputImpl(), false);
    }

    return hookResult;
  }

I don't see any path where it fails early, which seems problematic: If package:foo depends on package:bar, both of them have build hooks and foos hook depends on outputs from bars hook, then if bar fails to build, we shouldn't even attempt to build foo.

Conservatively it could fail after the first package that failed to build or verify correctly.

Slightly better would be to have a graph (or more precisely a DAG) and build everything whose dependencies have transitively been successfully built, but never attempt to build a package that has any transitive dependencies with build failures.

[dcharkes]

Better to verify, but I may have fixed that as well in 5164777

I'll fix this, or if it's already fixed, add a regression test.

Conservatively it could fail after the first package that failed to build or verify correctly.

This is what ninja does. It does not try to build all reachable targets. It stops building new targets after it encounters the first failure. (Ninja does finish building all targets that are already being built concurrently with -j1000.)

Slightly better would be to have a graph (or more precisely a DAG) and build everything whose dependencies have transitively been successfully built, but never attempt to build a package that has any transitive dependencies with build failures.

That increases the latency. And requires users to ctrl+c the build if they already know how to fix the issue. So, maybe it's better if we stick to early failure like ninja.