Message ID | 20210819020234.642522-1-contact@robbyzambito.me |
---|---|
State | Accepted |
Headers | show |
Series | [bug#50084,v3] gnu: waypipe: Clean up phases and dependencies. | expand |
Context | Check | Description |
---|---|---|
cbaines/applying patch | fail | View Laminar job |
cbaines/issue | success | View issue |
cbaines/applying patch | fail | View Laminar job |
cbaines/issue | success | View issue |
On Wednesday, August 18th, 2021 at 22:02, Robby Zambito <contact@robbyzambito.me> wrote: > I'm a bit confused as to why test dependencies are supposed to be > native-inputs. Aren't the tests run on the target architecture, not the > build machine architecture? And aren't native-inputs built for the build > machine architecture? You might be right. I haven't yet done any cross compiling with Guix yet, so I don't know much about it. I'll have to let someone with more knowledge comment on this. Best regards, Paul
Robby Zambito schreef op wo 18-08-2021 om 22:02 [-0400]: > * gnu/packages/xdisorg.scm (waypipe)[arguments]: Remove unused > argument from fix-sleep-path phase. > [native-inputs]: Add python, coreutils. > [inputs]: Remove python, coreutils. > --- > Paul, > > Thank you for the tips. I've removed the unused outputs argument, as > well as the out variable. > > I'm a bit confused as to why test dependencies are supposed to be > native-inputs. Aren't the tests run on the target architecture, not the > build machine architecture? And aren't native-inputs built for the build > machine architecture? By default, tests are never run when cross-compiling, so putting test dependencies in 'native-inputs' works in practice. Theoretically, putting test dependencies in 'inputs' might be cleaner, especially if at some point Guix supports testing cross-compiled packages (maybe the build directory could be copied to a "worktree" output or something, and guix could provide a command to test the cross-compiled binaries on the machine that was cross-compiled for or something). Nevertheless, test dependencies tend to be put in 'native-input' anyways. This has a practical reason (*): not all build systems support cross-compilation. E.g., the build system 'meson', used by 'glib', doesn't support cross-compilation on 'master' (it does on 'core-updates-frozen' though), so packages that (indirectly) have 'glib' as 'input' cannot be an 'input'. (*) not necessarily the reason people originally had in mind. > I cross compiled the package for armhf-linux and aarch64-linux and it > built and tested fine with the changes you suggested, but I also did the Are you sure it tested? Unless qemu transparent emulation is enabled (see ‘Transparent Emulation with QEMU’ in the manual) that cannot happen. Greetings, Maxime.
Hi Maxime, Thank you for the insight. > > I cross compiled the package for armhf-linux and aarch64-linux and it > > built and tested fine with the changes you suggested, but I also did the > > Are you sure it tested? Unless qemu transparent emulation is enabled > (see ‘Transparent Emulation with QEMU’ in the manual) that cannot happen. I just ran it again to be sure, and yes. I did set up QEMU for building on other architectures. I suppose this means QEMU is being used for the 'native-inputs', which is a little confusing but I guess it makes sense :D With the current state of these patches it follows the practice of putting the test dependencies in the native-inputs. If there is anything else that is needed before this can be merged I will be happy to make it happen! Sincerely, Robby
Robby Zambito schreef op do 19-08-2021 om 15:58 [-0400]: > Hi Maxime, > > Thank you for the insight. > > > > I cross compiled the package for armhf-linux and aarch64-linux and it > > > built and tested fine with the changes you suggested, but I also did the > > > > Are you sure it tested? Unless qemu transparent emulation is enabled > > (see ‘Transparent Emulation with QEMU’ in the manual) that cannot happen. > > I just ran it again to be sure, and yes. I did set up QEMU for building > on other architectures. I suppose this means QEMU is being used for the > 'native-inputs', which is a little confusing but I guess it makes sense > :D It is impossible to cross-compile waypipe on master, because meson-build-system does not support cross-compilation (on master). # replace 'glib' with 'waypipe' $ LC_ALL=C guix build glib --target=arm-linux-gnueabihf guix build: error: gnu/packages/glib.scm:425:2: glib@2.62.6: build system `meson' does not support cross builds What branch are you on? Also, what arguments did you pass to "guix build"? You need --target=arm-linux-gnueabihf for cross-compilation, not --system=armhf-linux. The latter is for offloading to an armhf machine or a QEMU emulated build. Greetings, Maxime.
diff --git a/gnu/packages/xdisorg.scm b/gnu/packages/xdisorg.scm index ba520d35ae..f5b041a590 100644 --- a/gnu/packages/xdisorg.scm +++ b/gnu/packages/xdisorg.scm @@ -885,19 +885,15 @@ include cursor in the resulting image.") `(#:phases (modify-phases %standard-phases (add-after 'unpack 'fix-sleep-path - (lambda* (#:key inputs outputs #:allow-other-keys) - (let ((out (assoc-ref outputs "out")) - (coreutils (assoc-ref inputs "coreutils"))) + (lambda* (#:key inputs #:allow-other-keys) + (let ((coreutils (assoc-ref inputs "coreutils"))) (substitute* "./test/startup_failure.py" - (("sleep") - (string-append coreutils "/bin/sleep"))) - #t)))))) + (("sleep") (string-append coreutils "/bin/sleep"))))))))) (native-inputs `(("pkg-config" ,pkg-config) - ("scdoc" ,scdoc))) - (inputs - ;; For tests - `(("python" ,python) + ("scdoc" ,scdoc) + ;; For tests + ("python" ,python) ("coreutils" ,coreutils))) (home-page "https://gitlab.freedesktop.org/mstoeckl/waypipe") (synopsis "Proxy for Wayland protocol applications")