Skip to content

Add support for the Rust programming language

Yann E. MORIN buildroot 1 version New

Get series with b4
b4 am 20171218152602.GA2903@scaer

Versions newest first

  1. v8 Latest0 of 9 patches 0 repliesNew

Patches in v8 No applies recorded yet

None of the 9 patches the cover letter announces are in this archive.

Reviews trailers per patch

No Reviewed-by, Acked-by or Tested-by trailers for v8 yet.

Read the v8 thread

Cover letter [Buildroot] [PATCH v8 0/9] Add support for the Rust programming language

Thomas, Eric, All,

On 2017-12-18 11:31 +0100, Thomas Petazzoni spake thusly:

Quoted 24 lines · Eric Le Bihan
Quoted 17 lines

The patch which adds the package to build Rust from source provides a patch to fix a problem involving files ending with *.orig.

As the Rust compiler is built using Cargo, the tarball contains vendored versions of the crates (e.g. src/vendor/backtrace-sys). Each crate contains a file named Cargo.toml.orig. An associated file named .cargo-checksum.json will contain a checksum for Cargo.toml.orig (and the other source files).

But support/scripts/apply-patches.sh will delete the Cargo.toml.orig files. This will cause the build to fail, as Cargo will not be able to find the file and verify the checksum.

So the patch included in the rust package removes all Cargo.toml.orig entries from the affected .cargo-checksum.json. As these files list all the source files, this results in a huge patch.

Quoted 5 lines

Besides, as these are non-indented JSON files, some are one-lined and thus the 998 characters limit enforced by git-send-email is exceeded.

So, if there a way to stop support/scripts/apply-patches.sh from pruning Cargo.toml.orig files, so this patch can be dropped?

Quoted 8 lines

Do we really have a reason to remove *.orig files in apply-patches.sh ? .orig backup files are only produced if -b is passed to patch, which we are not using.

Are there other cases where .orig files are produced by patch *and* we really need to remove them?

Peter, Arnout, Yann?

I have no idea about this, but the removal of .orig file has been there since the dawn of ages, more than 15 years ago now, and the reason is not explained.

I think we could very well live with .orig files, though.

Alternatively, we could set and export SIMPLE_BACKUP_SUFFIX=.orig.br (or to any other singling-out value) which will force the backup suffix just in case, and then we only remove those files.

Yet, this is adding a bit of complexity, when we could probably lives happy with .orig files.

Except I suspect some badly-behaving packages could very well do things like:

    data:
        call_my_tool $(wildcard #(top_srcdir)/data/*)

and thus, if we happen to patch a file in the data/ subdir, we'd break the build of that package.

So, I would go for not removing .orig files, and in case there is one package where this causes a problem, either we fix it, or we add a post-patch hook to remove the .orig files, or we switch to using the SIMPLE_BACKUP_SUFFIX variable if too many packages are impacted.

Deal? ;-)

Regards,
Yann E. MORIN.

Signature · 6 lines
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

Read the cover letter in its thread