[ltt-dev] UST communication library

[alexandre.montplaisir@polymtl.ca (Alexandre Montplaisir)]

On 11-06-15 11:16 AM, David Goulet wrote:
> On 11-06-15 11:01 AM, Yannick Brosseau wrote:
>>>>> 1) Keep libustcomm in UST and linking it in lttng-tools. Cons : direct
>>>>> dependency! ... not good
>>>> 1b) Have an *optional* dependency on UST. At configure time, lttng-tools could
>>>> check if libust is present, if so compile it with UST support. If not, only
>>>> compile with kernel support. ("Warning, libust not found, UST support will not
>>>> be available", something like that)
>>> This is problematic for packaging...
>> No, this is not problematic. When we create a package, we just have to
>> build-depend on UST. That way, people who wants to build it by hand
>> without UST, don't need to install UST.
>> Also, for distro like gentoo, you can build your package with UST support.
>>
> Enlighten me Yannick :)
>
> # apt-get install lttng-tools
>
> How are you going to have the UST support without installing the UST package
> (assuming that libustcomm is inside ust) ?

The optional dependency would be at compile time (during the configure). 
For distribution packages, it's up to the packager to decide which 
options to turn on/off. In this very case, it would make sense to turn 
it on, so the lttng-tools .deb (or .rpm, etc.) package would depend on 
the libust one. But at the "source package" level, the dependency would 
be optional.

This allows users with specific requirements (limited space, embedded 
targets,...) to compile/configure the way they see fit, but for generic 
users who just "apt-get install", they have all the options enabled.

This is exactly what happens with big configurable programs (mplayer, 
wine, etc.) where the source package has all the knobs and it's up to 
the distribution packaging to provide a sane set of defaults.

>
> I figure you'll have a "Not found libust.so..." at execution time ?
>
> David
>
>> Yannick
>>
>>
-- 
Alexandre Montplaisir
DORSAL lab,
?cole Polytechnique de Montr?al