| Age | Commit message (Collapse) | Author | |
|---|---|---|---|
| 2024-11-07 | Build iwyu as a linting tool of clang-18 | Maksim Denisov | |
| Co-authored-by: Paul Cristian Sarbu <paul.cristian.sarbu@huawei.com> | |||
| 2024-11-07 | Simplify logic of INCLUDE_LINTER lookup in clang-18 | Maksim Denisov | |
| 2024-11-07 | Install binutils for clang-18 to a separate directory | Maksim Denisov | |
| ...to avoid potential staging conflicts. | |||
| 2024-11-07 | Use quote to simplify build descriptions | Klaus Aehlig | |
| 2024-11-05 | Update rules reference | Klaus Aehlig | |
| 2024-10-23 | Update rules | Klaus Aehlig | |
| 2024-10-22 | Update rules | Klaus Aehlig | |
| 2024-09-27 | Update rules-cc | Klaus Aehlig | |
| 2024-09-27 | toolchains: move python to shell defaults | Klaus Aehlig | |
| ... and drop unneeded duplication as well as wrong expansion variables in "PATH" fields. | |||
| 2024-09-27 | clang: use provided ${CMAKE} variable | Klaus Aehlig | |
| ... instead of hard-coding the name cmake. | |||
| 2024-09-27 | ["CC/foreign", "defaults"] of stage-1: drop busybox | Klaus Aehlig | |
| ... 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. | |||
| 2024-09-27 | Drop wrong and unneed toolchain reference in defaults target | Klaus Aehlig | |
| 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. | |||
| 2024-09-27 | clang: set CMAKE_MAKE_PROGRAM explicitly to ${MAKE} | Klaus Aehlig | |
| ... instead of relying on cmake to pick it up from path. | |||
| 2024-09-27 | cmake: set CMAKE_MAKE_PROGRAM to ${MAKE} | Klaus Aehlig | |
| ... as, during bootstrap, when searching for a make utility, the environment variable ${MAKE} is not honored as default for CMAKE_MAKE_PROGRAM. | |||
| 2024-09-27 | make: bring in directory of CC as default path | Klaus Aehlig | |
| ... so that other tools of the CC toolchain that might be called directly are available. | |||
| 2024-09-27 | busybox: Add directory of CC to path | Klaus Aehlig | |
| ... as certain configure scripts call the compiler by basename | |||
| 2024-08-23 | clang: Add support for building clang-tidy | Oliver Reiche | |
| 2024-08-08 | etc/repos.json: have file root have the to_git pragma | Klaus Aehlig | |
| 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. | |||
| 2024-07-09 | Bump clang 18 to 18.1.8 | Oliver Reiche | |
| 2024-07-09 | Bump gcc 13 to 13.3.0 | Oliver Reiche | |
| 2024-07-03 | test rules: use full stage-0 busybox | Klaus Aehlig | |
| ... 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. | |||
| 2024-07-03 | update rules | Klaus Aehlig | |
| 2024-07-03 | test.TARGETS: inherit shell and foreign toolchain | Klaus Aehlig | |
| ... and also add the missing bindings for the remaining test rules. | |||
| 2024-07-03 | bootstrap busybox: install with deps | Klaus Aehlig | |
| 2024-07-03 | stage-0/gcc wrapper: point to a parallel directory | Klaus Aehlig | |
| ... so that we can install-with-deps the wrapper, in case the bootstrap compiler has dependencies not present on the host machine. | |||
| 2024-07-03 | expand_exec: install with deps | Klaus Aehlig | |
| 2024-07-01 | complier+tools.TARGETS: fix reference to toolchain defaults | Klaus Aehlig | |
| 2024-06-28 | CC toolchains: remove wrong reference to $(TOOLCHAIN) in PATH | Klaus Aehlig | |
| 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. | |||
| 2024-06-28 | toolchain: set shell toolchain, whenever busybox is available | Klaus Aehlig | |
| 2024-06-28 | Document that coreutils are no longer a requirement | Klaus Aehlig | |
| 2024-06-28 | Production stages: use ["shell", "cmds"] | Klaus Aehlig | |
| ... instead of generic to support bringing in a toolchain. | |||
| 2024-06-28 | Production stages: inherit shell toolchain | Klaus Aehlig | |
| 2024-06-28 | Higher stages: reuse stage-0's expand_exec | Klaus Aehlig | |
| 2024-06-28 | stage-1: add shell defaults | Klaus Aehlig | |
| ... using the full busybox from stage-0 | |||
| 2024-06-28 | stage-0/gcc: separate gcc.real from wrapping and use compiled wrapper | Klaus Aehlig | |
| 2024-06-28 | stage-0/gcc: copy file to work around source modification in place | Klaus Aehlig | |
| 2024-06-28 | stage-0/gcc: use our own sh as interpreter | Klaus Aehlig | |
| 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. | |||
| 2024-06-28 | stage-0/binutils: explicitly declare absence of C++ compiler | Klaus Aehlig | |
| ... in a way that is supported by configure scripts without any guessing. | |||
| 2024-06-28 | stage-0/binutils: use interpreter | Klaus Aehlig | |
| ... instead of relying on hard-coded /bin/sh in the #!-line. Also add our interpreter in scripts that are called directly during the build. | |||
| 2024-06-28 | stage-0/make: directly call the interpreter | Klaus Aehlig | |
| ... instead of relying on the #!-line that hard-codes /bin/sh. | |||
| 2024-06-28 | Update rules | Klaus Aehlig | |
| ... to a version supporting shell toolchains. | |||
| 2024-06-28 | stage-0: Use C-version of expand_exec | Klaus Aehlig | |
| ... thus having less requirements on our bootstrapped shell tool chain. | |||
| 2024-06-28 | stage-0: use bootstrapped ash as shell | Klaus Aehlig | |
| 2024-06-28 | stage-0/busybox: bootstrap more utils | Klaus Aehlig | |
| 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. | |||
| 2024-06-28 | stage-0/busybox: Also bootstrap ash | Oliver Reiche | |
| 2024-05-16 | Provide shell defaults for the tests | Klaus Aehlig | |
| 2024-05-16 | Update rules to a version supporting shell defaults | Klaus Aehlig | |
| 2024-05-16 | shell defaults: use qualified rule reference | Klaus Aehlig | |
| 2024-05-16 | shell toolchain: for the time being, use host | Klaus Aehlig | |
| Now that the rules-cc support toolchain definitions for the shell, document the current status quo that the shell is (still) taken from host. | |||
| 2024-05-13 | Add gcc 14.1.0 | Oliver Reiche | |
 |
index : ~aehlig/just-buildsystem/bootstrappable-toolchain.git | |
| A C/C++ toolchain bootstrappable out of a C compiler (with libc) and /bin/sh. | Klaus Aehlig |
| summaryrefslogtreecommitdiff |