Remove CCompiler.{envScript,envScriptArgs} and replace by other means
#1606
Comments
|
/cc @dcharkes For discussion |
|
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.)
Every user will have to do that, that sounds horrible. Without the env vars basically no compilation can succeed.
That could work, but that requires us to do this in multiple places:
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. |
I could imagine having some helper function somewhere that invokes this That shared helper can be used by all bundling tools (of which there's very few) when determining the To me this seems better than exposing |
|
Another consideration is doing unneeded work if no code assets are built. If we do this inside If we always invoke the script we should consider just putting the environment variables into the environment the hook is invoked with. Then we can completely omit a |
It feels a bit weird though that we would add env vars to be able to run executables, but we don't also simply prepend the directory with the executables to the path. E.g. the environment we decide to pass in becomes part of the contract for
Either way, we have windows-specific details in the API, either in the Completely removing them is also ugly. We'd be providing half the information needed to run the C compiler. We should provide all or none. And none doesn't work either because we'd like the C code to be compiled with the same C compiler as the Flutter native app is compiled. |
|
To me all options on the table seem better then status quo with
Maybe we can do some research how others solve this issue?
Well flutter tools always runs |
CMake seems to require vcvars.bat to have been called already, so that the environment variables are already set. And people try to jump through all kinds of hoops to try to make their CMake still work if it wasn't set.
In the Dart SDK GN build files we jump through those kind of hoops to extract the vcvars into the environment in We have two cases:
Case (2) is similar to what we do in the SDK, nothing is provided from the outside, just figure it out yourself. Of course this means Case (1) is most similar to XCode and VS calling |
|
Thanks for the investigation, @dcharkes ! So it sounds like nobody else is doing what we currently do (i.e. passing along the |
As noted in #1739 (comment): If we change the
One quirk is that Postponing the modification of
Or, more along the lines of the current situation, which we are trying to get rid of. Or, more along the lines of not passing the env-script and trying to find it based on the final vcDir = toolInstance.uri.resolve('../../../../../../');
final batchScript = vcDir.resolve('Auxiliary/Build/$fileName');(But it would be rather weird that For reference, the modified environment variables: |
|
Another thought: The gcc/clang abstraction with having 3 executables is also kind of leaking out. Not every native toolchain will have this separation of 3 executables. In To avoid having to reverse engineer what compiler is provided, maybe we should embrace specifying which compiler it is and change the compiler config to: input.config.code.cCompiler.compiler: 'clang'
input.config.code.cCompiler.clang.cc: 'path/to/clang'
input.config.code.cCompiler.clang.ld: 'path/to/lld.ld'
input.config.code.cCompiler.clang.ar: 'path/to/ar'This would prevent If we go that route, then it's not so much of a leak anymore if we do pas (We do have to specify which of the two options it is though, otherwise the embedders and |
How precise for clang compilers?If we go into the direction of making explicit which c-compiler is being passed in the input.config.code.cCompiler.compiler: 'clang' // or 'msvc'
input.config.code.cCompiler.clang.compiler: 'path/to/clang'
input.config.code.cCompiler.clang.linker: 'path/to/ld.lld'
input.config.code.cCompiler.clang.archiver: 'path/to/llvm-ar'
input.config.code.cCompiler.msvc.compiler: 'path/to/cl.exe'
input.config.code.cCompiler.msvc.linker: 'path/to/link.exe'
input.config.code.cCompiler.msvc.archiver: 'path/to/lib.exe'
input.config.code.cCompiler.msvc.archiver: 'path/to/lib.exe'
input.config.code.cCompiler.msvc.vcvars: 'path/to/vcvars64.bat'vs input.config.code.cCompiler.compiler: 'clang' // 'apple', 'gcc', 'ndk', 'msvc'
input.config.code.cCompiler.apple.compiler: 'path/to/clang'
input.config.code.cCompiler.apple.linker: 'path/to/ld'
input.config.code.cCompiler.apple.archiver: 'path/to/ar'
input.config.code.cCompiler.clang.compiler: 'path/to/clang'
input.config.code.cCompiler.clang.linker: 'path/to/ld.lld'
input.config.code.cCompiler.clang.archiver: 'path/to/llvm-ar'
input.config.code.cCompiler.gcc.compiler: 'path/to/x86_64-linux-gnu-gcc'
input.config.code.cCompiler.gcc.linker: 'path/to/x86_64-linux-gnu-ld'
input.config.code.cCompiler.gcc.archiver: 'path/to/x86_64-linux-gnu-gcc-ar'
input.config.code.cCompiler.msvc.compiler: 'path/to/cl.exe'
input.config.code.cCompiler.msvc.linker: 'path/to/link.exe'
input.config.code.cCompiler.msvc.archiver: 'path/to/lib.exe'
input.config.code.cCompiler.msvc.vcvars: 'path/to/vcvars64.bat'
input.config.code.cCompiler.ndk.compiler: 'path/to/clang'
input.config.code.cCompiler.ndk.linker: 'path/to/ld.lld'
input.config.code.cCompiler.ndk.archiver: 'path/to/llvm-ar'Specifying the compiler family Currently we get away with not specifying which compiler is passed in by pattern matching on the file name and output on stdout after invoking with So I'm leaning towards specifying the clang-like compilers per compiler family so that the "recognizer" doesn't have to do guesswork file file names and What should the API for MSVC be?A. Pass the path to vcvars.bat - This is simply part of how the MSVC toolchain works, so make it explicit and let packages wrapping the MSVC compiler deal with it (e.g. Now, let's consider we write a A. I believe C. might break other build systems. All are somewhat reasonable options. @mosuem @mkustermann Any preferences? |
|
From a discussion with @mkustermann:
|
Currently we have the following class:
It is very weird to have
envScriptandenvScriptArgshere. It seems that windows-specific details are being exposed by this API.We should consider removing these two fields and instead do that differently:
class CCompilerConfig { final Map<String, String> environmentVariables; }that encapsulate the additional environment variables needed when invokingCCompilerConfig.{compiler,linker,archiver}The text was updated successfully, but these errors were encountered: