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
_______________________________________________
ltt-dev mailing list
[email protected]
http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
