mirror of
https://github.com/godotengine/buildroot.git
synced 2026-01-06 18:09:44 +03:00
59b2e826f2a6c1874c5d032d3a5852326028bc0e
In commit04154a6517(support/download/cargo-post-process: cargo output for vendor config), we switched away from our hand-crafted cargo.toml mangling, to use cargo itself to update that file. In doing so, we enabled the shell pipefail option, so that we could catch cargo failures, while redirecting its output through tee to the cargo.toml. However, pipefail is overzealous, and will hit us even for pipes we do not want to globally fail, like the one that actually checks whether an archive is already vendored or not: if tar tf "${output}" | grep -q "^[^/]*/VENDOR" ; then ... with pipefail, the above may always fail: - if the tarball is already vendored, grep will exit on the first match because of -q (it only needs a single match to decide that its return code will be zero), so the | will get closed, and tar may get -EPIPE before it had a chance to finish listing the archive, and thus would terminate in error; - if the tarball is not vendored, grep will exit in error. It turns out that the tee was only added so that we could see the messages emitted by cargo, and still fill the cargo.tom with the output of cargo. But that's a bit overkill: the cargo messages are going to stderr, and the blurb to add to cargo.toml to stdout, so we just need to redirect stdout. Yes, we do not see what cargo added to cargo.toml, but that is not so interesting. Still, cargo ends its messages with a suggestion for the user to modify cargo.toml, with: To use vendored sources, add this to your .cargo/config.toml for this project: But since we've already redirected that to cargo.toml, there is nothing for the user to edit, so the above can get confusing. Emit a little blurb that states that everything is under control. And then we can drop pipefail. Note: the go-post-process initially had pipefail too, but it was dropped inbfd1a31d0e(support/download/go-post-process: drop -o pipefail) as it was causing spurious breakage when extracting the archive before vendoring, so it is only reasonable that we also remove it from the cargo-post-process. Reported-by: Peter Korsgaard <peter@korsgaard.com> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Cc: Simon Richter <simon.richter@ptwdosimetry.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
…
Buildroot is a simple, efficient and easy-to-use tool to generate embedded Linux systems through cross-compilation. The documentation can be found in docs/manual. You can generate a text document with 'make manual-text' and read output/docs/manual/manual.text. Online documentation can be found at http://buildroot.org/docs.html To build and use the buildroot stuff, do the following: 1) run 'make menuconfig' 2) select the target architecture and the packages you wish to compile 3) run 'make' 4) wait while it compiles 5) find the kernel, bootloader, root filesystem, etc. in output/images You do not need to be root to build or run buildroot. Have fun! Buildroot comes with a basic configuration for a number of boards. Run 'make list-defconfigs' to view the list of provided configurations. Please feed suggestions, bug reports, insults, and bribes back to the buildroot mailing list: buildroot@buildroot.org You can also find us on #buildroot on OFTC IRC. If you would like to contribute patches, please read https://buildroot.org/manual.html#submitting-patches
Description
Godot's buildroot soft-fork for generating toolchains to make portable Linux releases of Godot games.
Languages
Makefile
66.1%
Python
13.6%
C
8.3%
Shell
6.2%
PHP
2.9%
Other
2.6%