Yes, I sort of agree, but personally I will run with this meanwhile. I
now recall what it was that made me do this: wasm. The wasm-pack system
requires the version of rustc to match with the wasm32-unknown-unknown
target, and I thought it better (read: easier :-) )to use the published
target instead of bootstrapping it myself. Esp. if the only reason is
to get matching version strings. As the tarball version is containing
the githash+date information I thought this was the easiest way. Call
me lazy :-) I still had to build rust myself since I wanted 1.39 for
other reasons.
I won't push for the offical port of yours to contain this, I just
wanted to contribute an idea. Do with it what you like. Maybe I will
open a ticket with rustc for the tarball to contain the version, it
makes sense I think.
/Niklas
On 2019-12-12 09:15, Sebastien Marie wrote:
On Thu, Dec 12, 2019 at 07:52:21AM +0100, Niklas Hallqvist wrote:
As a matter of fact I did the same update just a week ago, and ended up in
exactly the same patch set as you, except for one thing:
The version reported by 'rust -V' normally include the git hash and date, and
some rust code out there depends on it (maybe dumb, but nevertheless it is).
it is currently expected for build from a tarball. git information is only
included when build from a git directory. so I am expecting that any rust
installed from distribution to share the same output. (but when installed from
rustup, it comes from a build from mozilla which is done using git)
if some rust crate depends on it, you should open a bug report.
it could be interesting to also open a bug report on rustc itself in order to
include the information for tarball too (the tarball contains at least the
commit-hash information).
Thanks.
