[bug#50756] [PATCH] gnu: Add lttng-tools.

["Ludovic Courtès" <ludo@gnu.org>]

Hi Olivier,

Did you have a chance to look into this?

  https://issues.guix.gnu.org/50756

TIA!

Ludo’.

Xinglu Chen <public@yoctocell.xyz> skribis:

> 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.