| Age | Commit message (Collapse) | Author |
|---|
|
... as that is brought in by the shell toolchain anyway. In that
way, we can also drop setting "PATH" and hence get rid of the
assumption that variable-expansion happens in "PATH" strings.
|
|
The "PATH" field in ["CC", "defaults"] is taken literally (currently
outside the foreign rules, in the future everywhere), so a reference
to the toolchain does not work. However, it is not necessary either,
so simply drop it.
|
|
... instead of relying on cmake to pick it up from path.
|
|
... as, during bootstrap, when searching for a make utility,
the environment variable ${MAKE} is not honored as default
for CMAKE_MAKE_PROGRAM.
|
|
... so that other tools of the CC toolchain that might be called directly are available.
|
|
... as certain configure scripts call the compiler by basename
|
|
|
|
The main use of the bootstrappable toolchain is to just-import-git(1)
it as toolchain to an existing project. However, it is an explicitly
supported use case to build just the toolchain as stand-alone binaries.
Therefore, also for that use case, make sure all repositories are
content fixed, so that the various bootstrap stages are eligible
for caching as export targets.
|
|
|
|
|
|
... and not only the bootstrap one. For tests, it is useful to
have tools like realpath(1) and date(1) that are not needed for
bootstrapping.
|
|
|
|
... and also add the missing bindings for the remaining test rules.
|
|
|
|
... so that we can install-with-deps the wrapper, in case the bootstrap
compiler has dependencies not present on the host machine.
|
|
|
|
|
|
The environment variable PATH is taken literally by the shell, without
any expansion. So, having a string like "$(TOOLCHAIN)/clang/bin"
in PATH does not change anything as we do not have a directory
with that name. Drop it for now. In the future we might add "bin
dirs" to the CC toolchain as well, but as long as our rules do not
support this, drop the wrong entry here.
|
|
|
|
|
|
... instead of generic to support bringing in a toolchain.
|
|
|
|
|
|
... using the full busybox from stage-0
|
|
|
|
|
|
Unfortunately, this does not entirely removes the requirement of
a /bin/sh being present, as awk(1) is invoked during the build to
use popen(3) in one place, a libc function that has a hard-coded
reference to /bin/sh. Nevertheless, using our interpreter wherever
possible greatly reduces the dependency on the host system.
|
|
... in a way that is supported by configure scripts without
any guessing.
|
|
... instead of relying on hard-coded /bin/sh in the #!-line.
Also add our interpreter in scripts that are called directly
during the build.
|
|
... instead of relying on the #!-line that hard-codes /bin/sh.
|
|
... to a version supporting shell toolchains.
|
|
... thus having less requirements on our bootstrapped shell tool chain.
|
|
|
|
In stage 0, bootstrap a pretty complete tool collection, so that
we can bring ourselves the tools needed by the configure scripts
of the early stages.
|
|
|
|
|
|
|
|
|
|
Now that the rules-cc support toolchain definitions for the shell,
document the current status quo that the shell is (still) taken
from host.
|
|
|
|
|
|
An intended use case of this bootstrappable toolchain is to be
imported as toolchain into other projects. However, only export
targets should be imported into other projects (a recommendation
that is a requirement when obtaineing the imported project via a
serve endpoint). Fix this by exporting the toolchains.
|
|
|
|
|
|
|
|
|
|
... which not only requires "/bin" (for "sh") but also
"/usr/bin" for coreutils ("dirname", "realpath", "chmod",
etc.), which are needed for compiler wrappers and the patch
runner script.
|
|
|
|
... to propagate foreign tools that are the same in each
rule set (e.g., busybox, make).
|
|
... as those rules are only used by tools.
|
