Tested qbe 0956b11331a8c0d5880fff1eb35e8f3ffdc452b8 harec d5d992c3 and 
hare ac4dfefc on Fedora Rawhide aarch64 and tests pass. A newer version
of qbe than the release is required because of the 'blit' instruction.
Can update the version of hare if versions of hare and qbe can be updated.
It seems a 1.1 release of qbe is in preparation.

qbe 1.1 is available https://c9x.me/compile/releases.html

I've just updated qbe - note that I am on long holiday until Mai/June, and mostly offline within that time.

Spec URL: https://download.copr.fedorainfracloud.org/results/fnux/hare-lang/fedora-rawhide-x86_64/06058966-hare/hare.spec
SRPM URL: https://download.copr.fedorainfracloud.org/results/fnux/hare-lang/fedora-rawhide-x86_64/06058966-hare/hare-0-20230610.8cfe393.src.rpm

Now builds on aarch64 :-) Note that harec needs to be updated if we want to build the latest hare revision in rawhide (https://src.fedoraproject.org/rpms/harec/pull-request/2).

I'm willing to take on maintainership of this project (qbe, harec, and hare) if it would be helpful. I have an updated build live on COPR that seems to be functional, but I would appreciate a review on it.

I've sent in PRs to the qbe and harec packages on s.fp.o, so besides their pending review, I would just need a review of the hare package:

SPEC: https://download.copr.fedorainfracloud.org/results/mroche/hare/fedora-rawhide-x86_64/06664676-hare/hare.spec
SRPM: https://download.copr.fedorainfracloud.org/results/mroche/hare/fedora-rawhide-x86_64/06664676-hare/hare-0.0.0%5E20231113.d56e1c8c-1.fc40.src.rpm

All three packages are build for both supported architectures, x86_64 and aarch64.

I should be able to help review whichever package we want to go forward with.

Mike, note that the current config.mk is incorrect. The <ARCH>_AS, <ARCH>_CC, and <ARCH>_LD are used for cross compilation (hare has builtin support for cross compilation similar to go) and should be set to the appropriate binaries from cross-binutils and cross-gcc. See https://harelang.org/blog/2022-09-06-cross-builds-with-hare/.

```
AARCH64_AS = aarch64-linux-gnu-as
AARCH64_CC = aarch64-linux-gnu-gcc
AARCH64_LD = aarch64-linux-gnu-ld

RISCV64_AS = riscv64-linux-gnu-as
RISCV64_CC = riscv64-linux-gnu-gcc
RISCV64_LD = riscv64-linux-gnu-ld

<NATIVE_ARCH>_AS = as
<NATIVE_ARCH>_CC = cc
<NATIVE_ARCH>_LD = ld
```

You can look at Alpine's packaging for an example [1]. There is a separate config.${arch}.mk file for each architecture. `${arch}_<TOOL>` is always set to `<TOOL>` in `config.${arch}.mk` and then `<OTHER_ARCH>-<TOOL>` are set to the binaries from cross-binutils / cross-gcc.

I would add best-effort support for riscv64 to the package as well for the sake of the Fedora RISCV project.

You don't need the `%global elbuild` thing. Just run `%set_build_flags` unconditionally.

[1]: https://gitlab.alpinelinux.org/alpine/aports/-/tree/master/community/hare

> The <ARCH>_AS, <ARCH>_CC, and <ARCH>_LD are used for cross compilation

Ah, that makes a lot more sense. Thanks for the pointers there, I'll make those corrections.

> I would add best-effort support for riscv64 to the package as well for the sake of the Fedora RISCV project.

As I haven't been playing super close attention, do you know if we have native riscv64 builders available for COPR builds? I can always kick off a scratch build, but it's nice to have things hosted somewhere as well for easy user testing.

> You don't need the `%global elbuild` thing. Just run `%set_build_flags` unconditionally.

I was doing that initially but seeing the double output on Fedora builds was irking me 😆 If I'm the only one, I can set it back to that.

You could probably do something like

```
%build
[...]
%{!?_auto_set_build_flags:%set_build_flags}
[...]
```

instead of conditionalizing based on EPEL.


>> I would add best-effort support for riscv64 to the package as well for the sake of the Fedora RISCV project.
>
> As I haven't been playing super close attention, do you know if we have native riscv64 builders available for COPR builds? I can always kick off a scratch build, but it's nice to have things hosted somewhere as well for easy user testing.

I'm not sure how to submit test builds for it. Fedora RISCV has its own Koji instance: http://fedora.riscv.rocks/koji/. It's not available in Copr. I would at least add a config for it and add it to ExclusiveArch even if you cannot run a test build.

May I suggest taking some inspiration from my local packaging of hare?

As of today it looks like this:

https://github.com/Dridi/dotfiles/blob/523fb5317185ce3da586ff82639e67de674cd6af/rpmbuild/SPECS/hare.spec

I solved the cross-compiling configuration and dependencies with Lua macros:

https://github.com/Dridi/dotfiles/blob/523fb5317185ce3da586ff82639e67de674cd6af/rpmbuild/SPECS/hare.spec#L37-L45
https://github.com/Dridi/dotfiles/blob/523fb5317185ce3da586ff82639e67de674cd6af/rpmbuild/SPECS/hare.spec#L67-L104

I also meant to make the qbe package install an RPM macro %{qbe_arches}:

https://github.com/Dridi/dotfiles/blob/523fb5317185ce3da586ff82639e67de674cd6af/rpmbuild/SPECS/hare.spec#L47-L48

But I did the work for my hare package:

https://github.com/Dridi/dotfiles/blob/523fb5317185ce3da586ff82639e67de674cd6af/rpmbuild/SPECS/hare.spec#L114-L121

The harec package should probably also expose a %{harec_arches} macro.

I also tried to extract linker flags from GCC LDFLAGS to feed the LDLINKFLAGS variable:

https://github.com/Dridi/dotfiles/blob/523fb5317185ce3da586ff82639e67de674cd6af/rpmbuild/SPECS/hare.spec#L5-L13

It appears to work on my machine, but probably needs scrutiny.

There are other things to consider and off the top of my head I remember wanting to look at tzdata integration and never did.

Adding this is probably enough:

    Requires: /usr/share/zoneinfo/leap-seconds.list

One strong recommendation I have is to separate the hare toolchain from the standard library. They have different licenses and purposes so that small complication simplify other things.

I tried to submit a patch upstream to make it easier to process module dependencies to add this to packaging, but my patch was conflicting with major ongoing refactoring, and until qbe and harec become recent-enough on my machine, I won't attempt a new patch. Right now my old rig is functional for my hare usage.

Hare packaging is currently not on my radar but I may remember other things now that it was brought up to my attention.

> Adding this is probably enough:
> 
>     Requires: /usr/share/zoneinfo/leap-seconds.list

Never mind, this is most likely not enough. The hare package should probably expose a %{hare_requires} macro with at least the above. All packages shipping hare programs should rely on having this file installed.

(In reply to Dridi Boukelmoune from comment #10)
> > Adding this is probably enough:
> > 
> >     Requires: /usr/share/zoneinfo/leap-seconds.list
> 
> Never mind, this is most likely not enough. The hare package should probably
> expose a %{hare_requires} macro with at least the above. All packages
> shipping hare programs should rely on having this file installed.

Side note: Dependencies like this are discouraged (SHOULD NOT):
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_file_and_directory_dependencies

And they will possibly be either broken or forbidden soon:
https://pagure.io/fesco/issue/3097

> Side note: Dependencies like this are discouraged (SHOULD NOT)

Indeed.

This could simply be a Requires on tzdata. There is a no separate subpackage for /usr/share/zoneinfo/leap-seconds.list.

As for new `%{qbe_arches}` and `%{hare_arches}` macros, those should be added to redhat-rpm-config directly or a hare-srpm-macros package that's part of the default buildroot (I prefer the latter) so packaged can use `ExclusiveArch: %{hare_arches}`. That can be handled down the line.

> This could simply be a Requires on tzdata.

That's exactly what I did in my spec.

> a hare-srpm-macros package that's part of the default buildroot

This is another thing I'm working on on the side, however I don't think this needs to be ready for the initial inclusion of Hare.

> I solved the cross-compiling configuration and dependencies with Lua macros

I have this fixed in my unpushed spec, but not using Lua. I don't think cross-compiling toolchains need to be installed by default or even as a recommends, so I have an optional -cross-compile-gnu subpackage that requires binutils and gcc for the correct non-native architectures.

The reason for the -gnu suffix is in the even that it is possible to use the llvm and clang utilities as a runtime override, then I'm giving it space to have a -cross-compile-llvm subpackage without needing to do any provides/obsoletes.

The config itself is still dynamically generated rather than having multiple architecture configs to select from, but it produces the correct output now.

(In reply to Fabio Valentini from comment #11)
> Side note: Dependencies like this are discouraged (SHOULD NOT):
> https://docs.fedoraproject.org/en-US/packaging-guidelines/
> #_file_and_directory_dependencies
> 
> And they will possibly be either broken or forbidden soon:
> https://pagure.io/fesco/issue/3097

Hello Fabio!

Thanks for the heads up, I was aware of this policy but forgot about it. I was not aware of the incoming DNF change.

My main motivation is that the time::chrono module explicitly loads this file, and I remembered something about tzdata being split for containers (https://fedoraproject.org/wiki/Changes/tzdata-minimal) and this would have made the selection of the right package transparent. It looks like tzdata-minimal is gone on my f39 laptop, I was not aware of the change being reverted.

Not much time to follow changes these days...

(In reply to Mike Rochefort from comment #13)
> > This could simply be a Requires on tzdata.
> 
> That's exactly what I did in my spec.

This is not enough, Hare programs including the time::chrono module, even indirectly, need this file to be installed at run time.

Either a dependency generator can deduce that, or a %{hare_expires} macro is offered to all packages written in Hare. The precedent I'm aware of is %{systemd_requires} for having used it on $DAYJOB.

> > a hare-srpm-macros package that's part of the default buildroot
> 
> This is another thing I'm working on on the side, however I don't think this
> needs to be ready for the initial inclusion of Hare.

In my spec (for my current personal usage) I didn't bother making an SRPM sub-package, but I think this should be provided one way or another from the beginning.

(In reply to Maxwell G from comment #12)
> As for new `%{qbe_arches}` and `%{hare_arches}` macros, those should be
> added to redhat-rpm-config directly or a hare-srpm-macros package that's
> part of the default buildroot (I prefer the latter) so packaged can use
> `ExclusiveArch: %{hare_arches}`. That can be handled down the line.

In my spec I made sure to distinguish between %{hare_build_arches} and %{hare_host_arches} as they may not always match. They currently don't.

(In reply to Mike Rochefort from comment #14)
> > I solved the cross-compiling configuration and dependencies with Lua macros
> 
> I have this fixed in my unpushed spec, but not using Lua. I don't think
> cross-compiling toolchains need to be installed by default or even as a
> recommends, so I have an optional -cross-compile-gnu subpackage that
> requires binutils and gcc for the correct non-native architectures.
> 
> The reason for the -gnu suffix is in the even that it is possible to use the
> llvm and clang utilities as a runtime override, then I'm giving it space to
> have a -cross-compile-llvm subpackage without needing to do any
> provides/obsoletes.
> 
> The config itself is still dynamically generated rather than having multiple
> architecture configs to select from, but it produces the correct output now.

How do you do that? The makefile that produces /usr/bin/hare with its default configuration for cross compilation, so from the sound of it you'd have to ship 3 hare binaries: one for the regular package and one for each cross toolchain.

Are you installing something like hare, hare-gnu and hare-llvm in %{_libdir}/hare/ and managing %{_bindir}/hare with update-alternatives?

As an end user this sounds like the opposite of the complications I'd want on day 1.

My 2 cents.

> This is not enough, Hare programs including the time::chrono module, even indirectly, need this file to be installed at run time.

As you said, that's something that can be handled by a dependency generator macro. For full transparency, right now I'm focusing on end-users being able to *use* Hare in Fedora, not maintainers packaging Hare authored software. If there needs to be a realignment on that, that's fine. I'm just focusing on what's absolutely needed for developers to start using the tool, and then performing incremental enhancements to round everything out.

> How do you do that? The makefile that produces /usr/bin/hare with its default configuration for cross compilation, so from the sound of it you'd have to ship 3 hare binaries: one for the regular package and one for each cross toolchain.

I think we're talking past each other here a bit. The gnu/llvm split I mentioned would be contingent on Hare being able to accept build-time overrides for those tools. In looking through the Hare source, it doesn't seem like that's the case today, but it's a discussion I can start on the hare-dev list. And adding -gnu even if it's the only sub-package available just implies it's for the gcc/binutils cross-compile toolset considering Clang/LLVM don't require separate tooling to my knowledge.

[As a side note, both Alpine and your spec include a definition for arch-ar. I didn't see this referenced anywhere in the Hare source. I do see harec as giving the option of which archive tool to use for compiling its code, but that's it.]

> As an end user this sounds like the opposite of the complications I'd want on day 1.

This just goes back to my earlier statement, I'm viewing things with two different end-users in mind: developers and package builders/maintainers. I have a number of things I'm thinking about from a macro standpoint, such as build and runtime dependency generators, a provides generator (for modules), and base variables. Right now I'm focusing on making it possible for a Fedora user to install and develop with Hare (hence my COPR).

I can continue to build things up that way if it's preferred and make sure the rpm/srpm macros are available as well before acceptance into Fedora, but in my opinion it would better to let people at least play with the technology and get involved in the language's ecosystem first.

I guess I can't dissociate my developer self from my package maintainer self. I'm the kind of developer who ships "dist" archives and RPMs for $DAYJOB :)

Regarding AR in the toolchain, it went away in the big rewrite of the build driver, the same refactoring that made me postpone a patch that would greatly ease the generation of provides/requires for hare modules. I'm purposefully stuck at an old hare commit because I don't want to also maintain qbe and harec locally, but once your pull requests get merged I may catch up with Hare development. It's going to be painful though, already behind a couple hundred patches...

The reason why I wanted cross compilation working out of the box in my spec is inspired the hare command that manages all the dirty details on your behalf, so you don't use harec and the rest of the toolchain directly. I find it much more friendly than having to fail an attempt and then having to figure how to make it work.

> The gnu/llvm split I mentioned would be contingent on Hare being able to accept build-time overrides for those tools.

Based on a quick conversation on the hare-users[0][1] list, it appears that hare will respect the AS, LD, and CC environment variables at runtime, so the config.mk definitions are a convenience fallback in case environment variables aren't set.

Accidentally sent that early.

So the door is open to try and approach of having there be a -gnu and -llvm sub-meta-package that pulls in the desired toolchains (while defaulting to GNU components in the build config).

Alternatively, we could have the GNU toolset (explicitly stated or subpackage) be a recommends for the standard install, and have the LLVM toolchain be an available subpackage.

[0] https://lists.sr.ht/~sircmpwn/hare-users/%3C72c7169b-d8ca-43c4-ae32-b7056d72e31d%40omenos.dev%3E
[1] https://lists.sr.ht/~sircmpwn/hare-users/%3C82d9d0de-ab96-4c2d-ae72-939873635151%40omenos.dev%3E

Update to the latest commits as of last night for all three projects:

qbe-1.1^20231230.5af33410-1
harec-0.0.0^20231210.9d51b367-1
hare-0.0.0^20231228.f01c8eed-2

The hare package now provides the following RPMs

hare :: Required meta package with licensing and /usr/share/doc info
hare-bin :: Executables and their man pages
hare-src :: Hare standard library and root third-party directory
hare-cross-compile-{gnu,llvm} :: Meta packages to obtain Hare cross compiling environments
    - GNU: binutils-{arch}-linux-gnu, gcc-{arch}-linux-gnu for non-%_arch packages, hare
    - LLVM: llvm, clang, lld, hare

Additionally I've added a convenience script to hare-bin, /usr/bin/harex. It is just a helper for running hare with non-GNU toolchains since they are already baked into the binary's config. It's controlled via the HARE_XCOMPILE_TOOLCHAIN environment var, presently looking for "llvm" as an accepted value. The only thing it sets are the AS, CC, and LD environment variables for a given run, and it checks if the user has defined any of those first before changing them. I tossed this in on a whim, but I have no qualms about removing it.

IMO, this is ready for inclusion in Fedora for end-users if approved, the next phase will be focused on making Hare code packager-friendly. But I'm still fully 

The following two package PRs are required for Hare to build correctly:

https://src.fedoraproject.org/rpms/qbe/pull-request/1
https://src.fedoraproject.org/rpms/harec/pull-request/3

https://download.copr.fedorainfracloud.org/results/mroche/hare/fedora-rawhide-x86_64/06836720-hare/hare.spec
https://download.copr.fedorainfracloud.org/results/mroche/hare/fedora-rawhide-x86_64/06836720-hare/hare-0.0.0%5E20231228.f01c8eed-2.fc40.src.rpm

Did it again...

* But I'm still fully open to any and all feedback regarding the work done here.

Hei Mike, thanks for your work. It looks good - but let's see the dependencies first.

As a side note: I'd rename the harex helper so that it doesn't look like it comes from upstream. Something around the line of `hare-cc-helper` or ``hare-fedora-cc-helper`?

Update: Both qbe[0] and harec[1] merge requests are done and waiting to be merged.

Hare finally has tagged releases, to both harec and hare are now using 0.24.0-rc1 and are no longer snapshot based (goodbye logic!). In the future, the harec will be provided as part of the main hare package, so there will need to be some decisions made at that point how to handle the relationship between it and the bootstrap harec package. That and working on a hare-rpm-macros package are topics that would be a good starting place for a Hare SIG.

As for the harex helper, I've decided to scrap it. It adds an extra (long) variable that just masks setting AS, CC, and LD yourself. Arguably those belong in a build config at compile time, and exported or prepended in a shell for interactive compilation.

SPEC: https://download.copr.fedorainfracloud.org/results/mroche/hare/fedora-rawhide-x86_64/06981286-hare/hare.spec
SRPM: https://download.copr.fedorainfracloud.org/results/mroche/hare/fedora-rawhide-x86_64/06981286-hare/hare-0.24.0~rc1-1.fc40.src.rpm

Alternative source view: https://pagure.io/mroche-copr-hare/hare

Final notes: the rpkg.conf is required for SCM builds on COPR to retrieve upstream tarballs; it will be removed if/when the package is approved for inclusion.

I have yet to do scratch builds on Fedora infra due to the QBE/harec requirements, but I do have F38, F39, Rawhide, and EPEL9 builds for x86_64 and aarch64 of all three packages in my COPR. Once the dependencies are fixed, I can take a look at verifying riscv64 builds.

[0] https://src.fedoraproject.org/rpms/qbe/pull-request/1
[1] https://src.fedoraproject.org/rpms/harec/pull-request/3

A few quick followups:

1. It looks like 0.24.0 will GA on Wednesday (2024.02.07) barring any technical issues[0].
2. I realized after sending the last message that Fedora does no officially support riscv64. So whenever Fedora gains mainline support for the architecture, the spec files will already be prepared.

[0] https://lists.sr.ht/~sircmpwn/hare-dev/%3CCYTMKCULMVED.2ECNTW09YAQZ8%40taiga%3E

Mike, can you please open a new review ticket for your package? You have to be the person who created the package review bug to be able to request a repo after the review is approved.

Done: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2262452

Thanks, Mike! I'll close this as a duplicate for now to avoid confusion.

*** This bug has been marked as a duplicate of bug 2262452 ***