[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Guix as a native-inputs ?

From: Olivier Dion
Subject: Re: Guix as a native-inputs ?
Date: Mon, 01 Aug 2022 18:05:22 -0400

On Mon, 01 Aug 2022, Tobias Geerinckx-Rice <> wrote:

> As ( implies, it's a strange thing to do.  There might be a better 
> solution to whatever your unspecified problem is.

Here's my full use case.

I do dynamic binary instrumentation.  I basicaly insert call/jump at
runtime in programs for executing callback.  I use Guix for its workflow
extension (GWL) to produce scientific metrics for my research.  I also
use Guix to run binaries in a profile with debug symbols available.  The
latter case is a stress test to see if the instrumenter keep the
integrity of the instrumented software.

For example I want to instrument `ls' from coreutils.  So I would need
`coreutils' and `coreutils:debug'.  These _could_ be added to the
native-inputs of my package.  However, I also want to test
instrumentation on many packages (~50).  These other packages lack the
`:debug' output that is required by my tools.  Furthermore, I don't want
to add a very long list of packages to my native-inputs and maintain it.

So what I do is that I have a Guix channel inside my project.  Inside
that channel I define all the packages that I need with the debug output
added.  I can then use them for testing like so
`guix shell -L .guix my-git my-git:debug'.

If you think there's a better solution then I'm open to heard it.

Olivier Dion

reply via email to

[Prev in Thread] Current Thread [Next in Thread]