Remove CCompiler.{envScript,envScriptArgs} and replace by other means

[mkustermann]

Currently we have the following class:

abstract final class CCompilerConfig {
  /// Path to a C compiler.
  Uri? get compiler;

  /// Path to a native linker.
  Uri? get linker;

  /// Path to a native archiver.
  Uri? get archiver;

  /// Path to script that sets environment variables for [compiler], [linker],
  /// and [archiver].
  Uri? get envScript;

  /// Arguments for [envScript].
  List<String>? get envScriptArgs;

  factory CCompilerConfig({
    Uri? archiver,
    Uri? compiler,
    Uri? linker,
    Uri? envScript,
    List<String>? envScriptArgs,
  }) = CCompilerConfigImpl;
}

It is very weird to have envScript and envScriptArgs here. It seems that windows-specific details are being exposed by this API.

We should consider removing these two fields and instead do that differently:

• Either add a class CCompilerConfig { final Map<String, String> environmentVariables; } that encapsulate the additional environment variables needed when invoking CCompilerConfig.{compiler,linker,archiver}
• Or have no replacement: The caller can figure out the additional environment, make wrapper-shell scripts for compiler/linker/archiver. Those wrapper shell scripts can set the needed environment and call the actual target compiler/linker/archiver

[mkustermann]

/cc @dcharkes For discussion

[dcharkes]

The way that the Windows commandline compiler works is that you're supposed to launch a different shell, that has all these env-vars set (including where to find standard libraries.)

• Or have no replacement:

Every user will have to do that, that sounds horrible. Without the env vars basically no compilation can succeed.

• Either add a class CCompilerConfig { final Map<String, String> environmentVariables; } that encapsulate the additional environment variables needed when invoking CCompilerConfig.{compiler,linker,archiver}

That could work, but that requires us to do this in multiple places:

1. flutter tools (or native_assets_builder, but we don't use it in Dartdev because we don't have a predefined compiler there.)
2. Dart CI

So the hacky code that runs the bash script to extract the vars would live in multiple places instead of one.

Not sure if that's cleaner or worse than the current solution.

[mkustermann]

That could work, but that requires us to do this in multiple places:

I could imagine having some helper function somewhere that invokes this envScript with envScriptArgs, sees what environment needs to be set and returns a Map<String, String>.

That shared helper can be used by all bundling tools (of which there's very few) when determining the CCompilerConfig.

To me this seems better than exposing CCompilerConfig.{envScript,envScriptArgs} in the build/hook.dart APIs (which will be seen by many package authors and - similar to me - some may be very confused what those two getters mean, when they have to be used, ...)