Re: Cross compilation status
Hi Mathieu, Am Sonntag, dem 10.09.2023 um 11:14 +0200 schrieb Mathieu Othacehe: > I have CC'ed members of the python, java, ruby, rust, r, haskell and > emacs teams. Any plans adding cross-compilation support to your > build-system, barriers to overcome? For Emacs, there are layers of problems. First things first, we are only doing byte compilation atm, which may or may not be arch-dependant based on stuff like endianness. For native compilation, there is the thing that even a slightly differently configured emacs won't load the packages you've just compiled without compiling it natively on its own. Granted, if we want to do cross-compilation, having just the bytecode might already be "good enough", but I wanted to throw this out there. I think we'd need some support from Emacs proper before we can start implementing cross builds. Cheers
Re: Cross compilation status
Hi Mathieu! Mathieu Othacehe writes: > Hello, > > In order for Guix to become an alternative to tools such as Yocto and > Buildroot, having most or all our packages cross-compiling is a > prerequisite. > > Here is a status of cross-compilation in Guix. For cross-compilation to > work, the build-system needs to support cross-compilation. > > The following build-systems explicitly refuse cross-compiling packages: > > haskell, agda, waf, chicken, rakudo, julia, python, emacs, rebar, > cargo, ruby, renpy, dub, android-ndk, scons, dune, ant, pyproject, > maven, asdf, r, ocaml, node For Python, it's already reported at: https://issues.guix.gnu.org/60733. And even implemented here: https://issues.guix.gnu.org/60849. Why it hasn't been merged yet is because it's coupled with a more daring change (unified build system for Python) and there were comments that this should be an all or nothing change, so I'd need to workout all the build systems and see what breakage happens at the global scale, which is a rather large undertaking. Maybe it could be decoupled from that change and tested in isolation, pushed first; we'd loose the benefit of the later change which is the ability to avoid wrapping native-inputs in our wrappers. -- Thanks, Maxim
Re: How can we decrease the cognitive overhead for contributors?
On Fri, Sep 08, 2023 at 04:20:30PM +0200, Ricardo Wurmus wrote: > > Josselin Poiret writes: > > > Regarding the “mom argument”, I would disagree and say that this is > > completely related: interruptions are more costly, you're more likely to > > have less attention span, and overall you probably don't want to commit > > to 20 steps just to send a contribution. > > That’s exactly it. > > I’m a parent working a full-time job and I’m easily overwhelmed by what > I would have considered to be simple processes 20 years ago. All these > simple and totally “easy” processes add up and – oops it’s 11:30pm > already and I had been feeling exhausted since 10am… > > There’s an hour before I pass out — what will I do with it? This thread > is about how we can reduce overhead; for me that would mean to have > certain checks automated, or to have commit messages be generated so I > only need to read them to sign off on them, etc. > > We all may gain from streamlining our processes. Personally, I see the > biggest problem in a lack of effective tools for reviewers, which > results in stretching out contribution interactions over weeks, months, > or years. This, to me, would be a way to increase the weight of the > rewards on the unbalanced scales that are overwhelmed by chores on the > other side. On the other hand, if we do manage to automate writing of commit messages, it makes one less thing for committers to manually fix before pushing the commit. The last couple of contributions I pushed had green checks on qa.guix.gnu.org and I felt at a bit of a loss what to do while checking it over. After checking that it was in fact green I double-checked the commit message and then also some of the layout of the commit and the package itself, and made sure it passed `guix lint`. More resources for qa.guix.gnu.org would let us build more patches more quickly. -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: Cross compilation status
On Sun, Sep 10, 2023 at 11:14:29AM +0200, Mathieu Othacehe wrote: > > Hello, > > In order for Guix to become an alternative to tools such as Yocto and > Buildroot, having most or all our packages cross-compiling is a > prerequisite. > > Here is a status of cross-compilation in Guix. For cross-compilation to > work, the build-system needs to support cross-compilation. > > The following build-systems explicitly refuse cross-compiling packages: > > > ocaml: 61 > haskell: 812 > maven: 2 > chicken: 12 > node: 57 > emacs: 1370 > dune: 289 > android-ndk: 12 > waf: 21 > julia: 300 > pyproject: 433 > r: 2441 > cargo: 3535 > ruby: 597 > rebar: 22 > scons: 15 > rakudo: 22 > agda: 6 > ant: 559 > python: 2488 > Cross-compilation KO: 13054 > --8<---cut here---end--->8--- > > Over the 28076 packages in Guix, 15065 are part of build-systems with > cross-compilation support and 13054 are part of build-systems without > cross-compilation support. > > Overall 46.5% of our packages will refuse to cross-compile with errors > such as: > > --8<---cut here---start->8--- > mathieu@meije ~$ guix build --target=aarch64-linux-gnu librsvg > guix build: error: gnu/packages/gnome.scm:3500:2: librsvg@2.54.5: build > system `cargo' does not support cross builds > --8<---cut here---end--->8--- > > I'd like to help converge towards the situation where all build-systems > support cross-compilation. > > I have CC'ed members of the python, java, ruby, rust, r, haskell and > emacs teams. Any plans adding cross-compilation support to your > build-system, barriers to overcome? I suspect librsvg is especially a problem since it is almost always pulled in with any sort of image building. I haven't looked at it closely yet, but I believe that in order to support cross-compilation support in rust we'll need to enable more targets, which will increase the build time for the final rust and the final output size. Considering that nothing built with rust links to it, I'm not convinced this is a problem. We will likely see people confused that we have a rust with cross-compiling abilities but with windows- and mac-specific (pre-compiled) libraries removed, so it wouldn't be able to cross-compile to those (or some other) platforms without changes. -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: Cross compilation status
On Sun, Sep 10, 2023 at 11:14:29AM +0200, Mathieu Othacehe wrote: > > I have CC'ed members of the python, java, ruby, rust, r, haskell and > emacs teams. Any plans adding cross-compilation support to your > build-system, barriers to overcome? Speaking as the one who added the rakudo build system and the perl6 packages, IMO all the perl6 packages should be removed and also the rakudo-build-system. I don't believe most of the packages have built for more than a year and I don't believe they have ever had any adoption. If it turns out that Raku (no longer perl6 for several years now) would make use of the current rakudo-build-system then we can always revert removing it. -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Cross compilation status
Hello, In order for Guix to become an alternative to tools such as Yocto and Buildroot, having most or all our packages cross-compiling is a prerequisite. Here is a status of cross-compilation in Guix. For cross-compilation to work, the build-system needs to support cross-compilation. The following build-systems explicitly refuse cross-compiling packages: haskell, agda, waf, chicken, rakudo, julia, python, emacs, rebar, cargo, ruby, renpy, dub, android-ndk, scons, dune, ant, pyproject, maven, asdf, r, ocaml, node while the rest of the build-systems do accept cross-compiling packages: clojure, qt, copy, minetest-mod, tree-sitter, raw, linux-module, glib-or-gtk, asdf/source, go, cmake, minify, perl, trivial, guile, elm, font, gnu, asdf/ecl, asdf/sbcl, meson, mozilla, texlive It does not mean that all the packages relying on those build-systems will cross-compile OK. It just means that we will at least try to build those. In term of numbers, the attached script produces the following output: --8<---cut here---start->8--- Total packages: 28076 clojure: 13 qt: 317 copy: 134 minetest-mod: 22 tree-sitter: 35 raw: 2 linux-module: 17 glib-or-gtk: 139 asdf/source: 794 go: 632 cmake: 1278 minify: 12 perl: 839 trivial: 250 guile: 49 elm: 30 font: 101 gnu: 4178 asdf/ecl: 753 asdf/sbcl: 814 meson: 504 mozilla: 2 texlive: 4150 Cross-compilation OK: 15065 ocaml: 61 haskell: 812 maven: 2 chicken: 12 node: 57 emacs: 1370 dune: 289 android-ndk: 12 waf: 21 julia: 300 pyproject: 433 r: 2441 cargo: 3535 ruby: 597 rebar: 22 scons: 15 rakudo: 22 agda: 6 ant: 559 python: 2488 Cross-compilation KO: 13054 --8<---cut here---end--->8--- Over the 28076 packages in Guix, 15065 are part of build-systems with cross-compilation support and 13054 are part of build-systems without cross-compilation support. Overall 46.5% of our packages will refuse to cross-compile with errors such as: --8<---cut here---start->8--- mathieu@meije ~$ guix build --target=aarch64-linux-gnu librsvg guix build: error: gnu/packages/gnome.scm:3500:2: librsvg@2.54.5: build system `cargo' does not support cross builds --8<---cut here---end--->8--- I'd like to help converge towards the situation where all build-systems support cross-compilation. I have CC'ed members of the python, java, ruby, rust, r, haskell and emacs teams. Any plans adding cross-compilation support to your build-system, barriers to overcome? Thanks, Mathieu cross.scm Description: Binary data
