[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#50756] [PATCH] gnu: Add lttng-tools.
From: |
Xinglu Chen |
Subject: |
[bug#50756] [PATCH] gnu: Add lttng-tools. |
Date: |
Sun, 26 Sep 2021 11:42:18 +0200 |
On Fri, Sep 24 2021, Olivier Dion via Guix-patches via wrote:
> On Fri, 24 Sep 2021, Xinglu Chen <public@yoctocell.xyz> wrote:
>> On Thu, Sep 23 2021, Olivier Dion via Guix-patches via wrote:
>
>>> +(define-public lttng-tools
>>> + (package
>>> + (name "lttng-tools")
>>> + (version "2.12.5")
>>
>> Version 2.13 is available; any reason for not using it?
>
> Would require to bump version of lttng-ust also I think. I prefer to do all
> of this
> in another patch.
Ah, OK.
>>> + (arguments
>>> + `(#:tests? #f
>>> + #:parallel-tests? #f
>>
>> There is no need to set #:parallel-tests? if #:tests? is set to #f.
>
> During my testing, I noticed that test in parallel are not working
> because of how the lttng-daemon works. So I disable the parallel option
> in order to not forget it when testing will work in the future. I
> should probably add a comment to explain the rationale here.
>
>>> + (propagated-inputs
>>> + `(("libkmod" ,kmod)
>>> + ("modprobe" ,module-init-tools)))
>>
>> Any reason for the labels not being the same as the package?
>
> I follow the naming convention in the description of the project's README
> so it's easier to map the dependencies described by it to Guix's
> packages. I can change this, but I find it more clear that way.
The name of the label is usually the same as the package, so I would
change them to “kmod” and “module-init-tools” respectively.
>>
>>> + (native-inputs
>>> + `(("pkg-config" ,pkg-config)
>>> + ("perl" ,perl)
>>> + ("libpfm4" ,libpfm4)
>>> + ("python" ,python-3)
>>
>> While running the configure script, I get
>>
>> configure: You may configure with --enable-python-bindings if you want
>> Python bindings.
>>
>> So you would have to pass the ‘--enable-python-bindings’ flag, and
>> Python would be needed during runtime as well.
>
> Does it tho? Bindings can be generated at build time. While you would
> require python-3 at runtime to use the bindings, you don't require
> python-3 to use the other tools of the project. I don't mind adding it
> to the inputs, I'm just asking.
True, the user can install always install Python in their profile
themselves.
signature.asc
Description: PGP signature