On 18/03/15 18:58, Martin Lucina wrote:
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.
Didn't you want to get rid of the configure wrapper?
Notably, it will work correctly unless the user exports the value and
forgets to unexport it before running the real make, leading to cryptic
error scenarios when trying to run the result.
Generally, I think relying on the env for toggles like this is asking
for trouble. I think we should follow the adage "first make it right,
then make it fast". If using a separate compiler for configure is not
right, and we can't figure out any other solution without obvious
drawbacks, I'd just as well have configure run slow.
One string we could pull from in the future is the fact that we're
crosscompiling, and the build system doesn't know how to run the
resulting binary. So we could pseudo-link the target, and then have
rumprun actually link it (and cache the result). That approach should
also solve cases where we'd want to crunch multiple binaries into a
single image. I'm sure there are examples and experiences of this type
of approach floating about, just need to survey them for the drawbacks.
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.
I'm sort a fan for the approach where you "." a crosscompile environment
which sets things, including PS1, to crosscompile mode. cf. how
rumpremote works.
