Background: We currently have two different compilers in app-tools, the normal compiler and a "stub" compiler used by the -configure wrapper. The reason for the existence of the stub compiler is that a lot of configure tests use a full compile and link to determine if X compiles, symbol Y is present, etc.
Now, a full compile and link is slow due to linking a full unikernel image each time, so it makes sense to optimize this. The current solution has the following problems: 1) It is specific to applications using configure/autoconf to build. 2) It relies on running configure with a *different* compiler (as far as it is concerned) and then overriding that compiler again in a separate -make wrapper back to the intended compiler. 3) As I found when trying to extend the same approach to applications using C++ by adding a c++.configure, some configure scripts that use libtool get confused if you try and build with a compiler that is different than the one you originally specified, resulting in an obscure "libtool: compile: unable to infer tagged configuration" error. [1] [2] I propose to fix this by enhancing our current cc wrapper to serve both purposes, and decide on whether or not to use the stub compiler based on the presence of an environment variable, e.g. RUMPRUN_USE_STUBCC. That way the name of the compiler being used is always the same, and the configure wrapper simply sets RUMPRUN_USE_STUBCC when calling configure. Setting the same environment variable when using e.g. CMake will allow it to benefit from the same optimization. If a user forgets to set the environment variable when running configure/CMake then everything will still work, just slowly. We could also drop the -make and -gmake wrappers as these would no longer serve any purpose aside from supporting software using "plain" Makefiles, but in that case I'd expect the user to set CC/CXX manually. Martin
