public inbox for gcc-rust@gcc.gnu.org
 help / color / mirror / Atom feed
From: Arthur Cohen <arthur.cohen@embecosm.com>
To: Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>,
	Andrew Pinski <pinskia@gmail.com>
Cc: pierre-emmanuel.patry@embecosm.com, gcc-patches@gcc.gnu.org,
	gcc-rust@gcc.gnu.org
Subject: Re: [PATCH] build: Check for cargo when building rust language
Date: Wed, 17 Apr 2024 16:54:19 +0200	[thread overview]
Message-ID: <45ff25ab-b39e-4f2d-84bd-a3ee8cfff98a@embecosm.com> (raw)
In-Reply-To: <yddh6g0be4y.fsf@CeBiTec.Uni-Bielefeld.DE>

Hi Rainer!

On 4/17/24 10:13, Rainer Orth wrote:
> Andrew Pinski <pinskia@gmail.com> writes:
> 
>> On Mon, Apr 8, 2024 at 9:39 AM <pierre-emmanuel.patry@embecosm.com> wrote:
>>>
>>> From: Pierre-Emmanuel Patry <pierre-emmanuel.patry@embecosm.com>
>>>
>>> Hello,
>>>
>>> The rust frontend requires cargo to build some of it's components,
>>> it's presence was not checked during configuration.
>>
>> WHY did this go in right before the release of GCC 14?
>> I don't get why this is considered temporary and it goes in right
>> before a release.
>> That seems broken to me.
> 
> two more questions about this:
> 
> Right now, the new cargo configure test disable rust on all of my
> targets (Solaris, Linux, Darwin) which didn't have it installed.  Before
> (as recent as last Friday), I could successfully build and test
> crab1/rust on all of them without cargo in sight.  So I wonder if the
> patch isn't premature.

We already have components depending on Rust libraries in our 
development repository, so this patch is important to ensure errors are 
emitted early during the configure phase rather than later at build 
time. I don't think this is premature, considering that your targets 
would fail to build the Rust frontend next time we upstream commits, 
which should happen this week or early next week.

> Besides, while there are packaged versions of cargo for Solaris 11.4 and
> Linux, Darwin hasn't anything (not checked Homebrew or similar yet).
> What's worse, rustup only supports macOS 10.12 and up, while I'm still
> regularly testing 10.7 and 10.11.  I don't really feel like building
> rust from source here (if it works at all).  This hasn't been an issue
> for any other languages that require additional tools for bootstrapping
> (like Ada or D): there are versions of GNAT around that still support
> those old Darwin releases, and I could use the C++ version of GDC in GCC
> 11.

Sorry, I'm not too familiar with the Rust situation on macOS. I am 
reading that starting from Rust version 1.74, the minimum macOS version 
required is indeed 10.12, released in 2016 I believe?

We currently depend on Rust version 1.72, so you should be able to 
install it on macOS 10.11. Maybe with rustup? You can try something like 
the following:

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y 
--default-toolchain=1.72.0;

which is the default installation method for Rustup, with version 1.72 
of the language specified. I'm not able to test this, sorry, but I'm 
very interested in knowing if it works. I think you can also install 
Rust using Homebrew, but again I am not able to test this and apologize.

The goal is to reduce that Rust version further soon anyway - we are 
going to target Rust version 1.49, released 3 years ago, as that is the 
version that gccrs aims to compile. This will bring us closer to 
compiling our dependencies with our own frontend.

> At the very least, the Rust situation needs to be documented clearly.

I'd love to work on this - what sort of documentation do you have in 
mind? Do you mean something like the online GCC documentation or an 
in-tree file? Let me know what you'd like me to add and I'll be happy to 
do so.

> 
> 	Rainer
> 

Kindly,

Arthur

  reply	other threads:[~2024-04-17 14:54 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-08 16:33 pierre-emmanuel.patry
2024-04-09  7:42 ` Richard Biener
2024-04-09  7:47 ` John Paul Adrian Glaubitz
2024-04-09  8:00   ` Jakub Jelinek
2024-04-09  8:29     ` John Paul Adrian Glaubitz
2024-04-09 10:40   ` Arthur Cohen
2024-04-09  8:55     ` Iain Sandoe
2024-04-09 12:01       ` Arthur Cohen
2024-04-09 10:09         ` Iain Sandoe
2024-04-09 13:53           ` Arthur Cohen
2024-04-09 14:12 ` Andrew Pinski
2024-04-09 14:25   ` Arthur Cohen
2024-04-15 11:14 ` Thomas Schwinge
2024-04-15 11:50   ` build: Don't check for host-prefixed 'cargo' program (was: [PATCH] build: Check for cargo when building rust language) Thomas Schwinge
2024-04-15 12:18     ` build: Don't check for host-prefixed 'cargo' program Pierre-Emmanuel Patry
2024-04-15 12:44   ` build: Use of cargo not yet supported here in Canadian cross configurations (was: [PATCH] build: Check for cargo when building rust language) Thomas Schwinge
2024-04-15 16:36     ` build: Use of cargo not yet supported here in Canadian cross configurations Pierre-Emmanuel Patry
2024-04-16  8:55     ` Arthur Cohen
2024-04-16 20:34 ` [PATCH] build: Check for cargo when building rust language Andrew Pinski
2024-04-17  8:13   ` Rainer Orth
2024-04-17 14:54     ` Arthur Cohen [this message]
2024-04-23  8:52       ` Rainer Orth

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=45ff25ab-b39e-4f2d-84bd-a3ee8cfff98a@embecosm.com \
    --to=arthur.cohen@embecosm.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=gcc-rust@gcc.gnu.org \
    --cc=pierre-emmanuel.patry@embecosm.com \
    --cc=pinskia@gmail.com \
    --cc=ro@CeBiTec.Uni-Bielefeld.DE \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).