Enable native backend on x86_64 GNU/Hurd

[sthibaul]

No description provided.

[sthibaul]

(The debian package does build fine there for instance)

[shindere]

Thanks! The configure script is versionned too so your PR should also update it. Something like `make configure` should do the hob for you.

[sthibaul]

The configure script is versionned too

Ah, there it is

[shindere]

Samuel Thibault (2024/11/03 06:01 -0800):

> The configure script is versionned too Ah, there it is

Thanks, as well for the Changes entry, to which we add the names of the reviewers. A possibly naïve question: as I understandyour patch, you enable the native backend not only on GNU Hurd specifically, but on all triples of the `x86_64-*-gnu*` form. Is such a move okay? Don't we want to be more restrictive and mention Hurd specifically in the triple? Also, out of curiosity: are there facilities to do some CI on Hurd?

[sthibaul]

as I understandyour patch, you enable the native backend not only on GNU Hurd specifically, but on all triples of the x86_64-*-gnu* form. Is such a move okay?

Normally, in configure, the matching against -gnu* is done last, to match only GNU/Hurd, by matching other GNU systems before that. I don't know why that wasn't done here. I have now reordered it.

are there facilities to do some CI on Hurd?

We do have a box where we already run some CI. I have however not seen much breakage on GNU/Hurd with ocaml on the past decade, so I don't think it'd really be useful to run CI is this case.

[shindere]

Samuel Thibault (2024/11/04 16:30 -0800):

> as I understandyour patch, you enable the native backend not only on GNU Hurd specifically, but on all triples of the `x86_64-*-gnu*` form. Is such a move okay? Normally, in `configure`, the matching against `-gnu*` is done last, to match only GNU/Hurd, by matching other GNU systems before that. I don't know why that wasn't done here.

Lack of experience of the original author in these matters, I fear. Perhaps also that we mildly try to avoid relying on the order of things and to make each matching very explicit because it feels easier to read for newcomers. Re: the changes entry I think your first line is not really relevant here as we try in this file to speak about user-visible changes. Also, as I already said you need to as a `reviewed by` fragment in this changes entry.

I have now reordered it.

I'm unsure we do want to do this, to be honest. Any opinion on whether we are comfortable with relyin gon the ordering, @dra27?

> are there facilities to do some CI on Hurd? We do have a box where we already run some CI. I have however not seen much breakage on GNU/Hurd with ocaml on the past decade, so I don't think it'd really be useful to run CI is this case.

Okay. I'd be curious to know whether the tests you mention include running thecompiler's testsuite, though.

[sthibaul]

Any opinion on whether we are comfortable with relying on the ordering

The problem is that as it is now we don't really have the choice, since some OSes decided to include a -gnu suffix in their osname (linux-gnu, kfreebsd-gnu, etc.), there will always be confusion.

[shindere]

Samuel Thibault (2024/11/05 02:56 -0800):

> Any opinion on whether we are comfortable with relying on the ordering The problem is that as it is now we don't really have the choice, since some OSes decided to include a `-gnu` suffix in their osname (linux-gnu, kfreebsd-gnu, etc.), there will always be confusion.

Okay.

[shindere]

Approved, thanks.

Cannot be merged yet, though, because there now is a conflict
in the Changes file.

May I please ask you to rebase and resolve the conflict?

And while you are at it, I confess I'd find it nice to also be
credited as a reviewer. ;)

[gasche]

Merged, thanks!