guix-devel
[Top][All Lists]
Advanced

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

Re: Package's inputs for developer?


From: Olivier Dion
Subject: Re: Package's inputs for developer?
Date: Mon, 07 Mar 2022 13:31:10 -0500

On Mon, 07 Mar 2022, Kaelyn <kaelyn.alexi@protonmail.com> wrote:
> On Sunday, March 6th, 2022 at 8:19 AM, Olivier Dion via "Development of GNU 
> Guix and the GNU System distribution." <guix-devel@gnu.org> wrote:
>
>> Hi Guix,
>>
>> I often find my self using inheritance of package to add native-inputs
>>
>> that are not stricly necessary for building the project, but are used
>>
>> for developement purpose like so:
>>
>> -------------------------------------------------
>>
>> (define base-native-inputs (list ...))
>>
>> (define my-package
>>
>> (package
>>
>> ...
>>
>> (native-inputs base-native-inputs)
>>
>> ...))
>>
>> ;; Developers version
>>
>> (package
>>
>> (inherit my-package)
>>
>> (native-inputs
>>
>> (append base-native-inputs
>>
>> (list gdb lcov))))
>>
>> -------------------------------------------------
>>
>> I guess this is the correct way of doing it or perhaps I should put gdb
>>
>> and lcov in the base-native-inputs?. But I was thinking that perhaps
>>
>> something like `(developer-inputs (list gdb lcov))` would be better,
>>
>> since these inputs are not stricly necessary for building the package.
>
> Can you give a bit more detail about what the use case is for adding
> developer tools as inputs?

Only for convenience of developing.  I also use the developer inputs for
continuous integration for generating coverage report for example.  I
guess that all of this can be wrapped under a script such as
`development-env` and use `guix shell` in it.

> The inheritance you describe seems more cumbersome than simply doing
> `guix shell gdb lcov -D my-package` to enter a development environment
> with gdb and lcov present, while also being a bit more limited when
> there are multiple tools with a similar function. In the above
> example, imagine if a developer wants to debug my-package using lldb
> instead of gdb--the developer-inputs would require transforming the
> package definition, but the ad-hoc invocation could simply be `guix
> shell lldb lcov -D my-package`.

I agree it's not very flexible.  I basically impose the usage of GDB
for debugging here.  I guess that using `guix shell` is the correct way
of doing so then.

Regards,
old

-- 
Olivier Dion
Polymtl



reply via email to

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