diff mbox series

[v2,1/3] kernel-shark: Reorder the priority when searching for trace-cmd libs

Message ID 20190313152220.22026-2-ykaradzhov@vmware.com (mailing list archive)
State Superseded
Headers show
Series Tuning the KernelShark build system | expand

Commit Message

Yordan Karadzhov March 13, 2019, 3:22 p.m. UTC
The CMAKE build system of KernelShark performs automated search for the
trace-cmd libraries, headers and executable before building the GUI.
The new order of the list of directories to search in is the following:

1. ${TRACE_CMD}/  ($TRACE_CMD is an environment variable)

2. CMAKE_SOURCE_DIR/../

3. Platform / system specific locations

Suggested-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Yordan Karadzhov <ykaradzhov@vmware.com>
---
 kernel-shark/build/FindTraceCmd.cmake | 16 +++++++++++++---
 1 file changed, 13 insertions(+), 3 deletions(-)

Comments

Patrick McLean March 13, 2019, 6:42 p.m. UTC | #1
On Wed, 13 Mar 2019 17:22:18 +0200
Yordan Karadzhov <ykaradzhov@vmware.com> wrote:

> The CMAKE build system of KernelShark performs automated search for
> the trace-cmd libraries, headers and executable before building the
> GUI. The new order of the list of directories to search in is the
> following:
> 
> 1. ${TRACE_CMD}/  ($TRACE_CMD is an environment variable)
> 
> 2. CMAKE_SOURCE_DIR/../
> 
> 3. Platform / system specific locations
> 

For system installs (especially when trace-cmd and trace-cmd are
separate packages), it's nicer to have trace-cmd install a pkgconfig
file. Then the kernelshark can cmake use pkgconfig for getting the
build options to find the headers, libraries, and binaries.

See https://people.freedesktop.org/~dbn/pkg-config-guide.html for
documentation on pkgconfig and pkgconfig files.
Steven Rostedt March 13, 2019, 7:06 p.m. UTC | #2
On Wed, 13 Mar 2019 11:42:35 -0700
Patrick McLean <chutzpah@gentoo.org> wrote:

> (especially when trace-cmd and trace-cmd are
> separate packages)

That should be a fun stunt. ;-)

But yeah, we are looking into separating KernelShark out of trace-cmd
in the future, but depending on libftrace.so (the guts of trace-cmd)
when that is ready. First we need to finish libtraceevent.so, which
will live in the Linux kernel git repo under tools/lib/traceeevent.
Would that be an issue in packaging libtraceevent?

-- Steve
Patrick McLean March 13, 2019, 8:32 p.m. UTC | #3
On Wed, 13 Mar 2019 15:06:02 -0400
Steven Rostedt <rostedt@goodmis.org> wrote:

> On Wed, 13 Mar 2019 11:42:35 -0700
> Patrick McLean <chutzpah@gentoo.org> wrote:
> 
> > (especially when trace-cmd and trace-cmd are
> > separate packages)  
> 
> That should be a fun stunt. ;-)
> 
> But yeah, we are looking into separating KernelShark out of trace-cmd
> in the future, but depending on libftrace.so (the guts of trace-cmd)
> when that is ready. First we need to finish libtraceevent.so, which
> will live in the Linux kernel git repo under tools/lib/traceeevent.
> Would that be an issue in packaging libtraceevent?
> 

Oops, editing error ;).

That is likely not an issue for distros that pick a kernel and stick
with it, they would just package the one that ships with the kernel
that version chose (barring any breaks with stable releases). On
distros that track upstream kernels, that would be kind of a pain to
deal with, but potentially still manageable by packaging the library
with the kernel (potentially with some LD_LIBRARY_PATH magic).

On Gentoo it would be very difficult to deal with, since kernels are
built by users, but I suspect that is kind of a niche. In practice
there would probably be a package that uses the kernel source tree to
build a "system" version (that is what is currently done with perf,
though unfortunately it lags a bit behind kernel releases).

I would imagine kernel developers would have to come up with a way to
handle it themselves, since they would have user space packages that
depend on a library produced from their kernel source tree.

I assume it will have a fairly stable API/ABI, so one would not have to
worry about recompiling userspace tools when a kernel gets updated?
Steven Rostedt March 18, 2019, 6:47 p.m. UTC | #4
On Wed, 13 Mar 2019 11:42:35 -0700
Patrick McLean <chutzpah@gentoo.org> wrote:

> On Wed, 13 Mar 2019 17:22:18 +0200
> Yordan Karadzhov <ykaradzhov@vmware.com> wrote:
> 
> > The CMAKE build system of KernelShark performs automated search for
> > the trace-cmd libraries, headers and executable before building the
> > GUI. The new order of the list of directories to search in is the
> > following:
> > 
> > 1. ${TRACE_CMD}/  ($TRACE_CMD is an environment variable)
> > 
> > 2. CMAKE_SOURCE_DIR/../
> > 
> > 3. Platform / system specific locations
> >   
> 
> For system installs (especially when trace-cmd and trace-cmd are
> separate packages), it's nicer to have trace-cmd install a pkgconfig
> file. Then the kernelshark can cmake use pkgconfig for getting the
> build options to find the headers, libraries, and binaries.
> 
> See https://people.freedesktop.org/~dbn/pkg-config-guide.html for
> documentation on pkgconfig and pkgconfig files.

Patrick,

Are you OK if I pull these patches in for now, and we sort out the
configurations later? I was holding this off, but found that some of
Yordan's other patches are dependent on this.

-- Steve
Patrick McLean March 18, 2019, 8:53 p.m. UTC | #5
On Mon, 18 Mar 2019 14:47:09 -0400
Steven Rostedt <rostedt@goodmis.org> wrote:

> On Wed, 13 Mar 2019 11:42:35 -0700
> Patrick McLean <chutzpah@gentoo.org> wrote:
> 
> > On Wed, 13 Mar 2019 17:22:18 +0200
> > Yordan Karadzhov <ykaradzhov@vmware.com> wrote:
> >   
> > > The CMAKE build system of KernelShark performs automated search
> > > for the trace-cmd libraries, headers and executable before
> > > building the GUI. The new order of the list of directories to
> > > search in is the following:
> > > 
> > > 1. ${TRACE_CMD}/  ($TRACE_CMD is an environment variable)
> > > 
> > > 2. CMAKE_SOURCE_DIR/../
> > > 
> > > 3. Platform / system specific locations
> > >     
> > 
> > For system installs (especially when trace-cmd and trace-cmd are
> > separate packages), it's nicer to have trace-cmd install a pkgconfig
> > file. Then the kernelshark can cmake use pkgconfig for getting the
> > build options to find the headers, libraries, and binaries.
> > 
> > See https://people.freedesktop.org/~dbn/pkg-config-guide.html for
> > documentation on pkgconfig and pkgconfig files.  
> 
> Patrick,
> 
> Are you OK if I pull these patches in for now, and we sort out the
> configurations later? I was holding this off, but found that some of
> Yordan's other patches are dependent on this.
> 

That's fine, my suggestions are more for long-term than an immediate
need. Most distros will probably work with the generic locations anyway.
Steven Rostedt March 26, 2019, 12:58 p.m. UTC | #6
On Wed, 13 Mar 2019 17:22:18 +0200
Yordan Karadzhov <ykaradzhov@vmware.com> wrote:

> The CMAKE build system of KernelShark performs automated search for the
> trace-cmd libraries, headers and executable before building the GUI.
> The new order of the list of directories to search in is the following:
> 
> 1. ${TRACE_CMD}/  ($TRACE_CMD is an environment variable)
> 
> 2. CMAKE_SOURCE_DIR/../
> 
> 3. Platform / system specific locations

I'm still confused. We shouldn't be looking for any paths at build time.
This should be done at run time.

Now, we can check the local directory that kernelshark lives in. That
is, if we are running from a fresh build, at start up, we can look at

 `pwd`/../lib | `pwd`/../../plugins

and see if those directories exist at run time. And if they do, we can
use them (as we would assume that the exec is running from a local
source tree).

I really don't want any build artifacts in the executable. This will
mean that you need to do special arrangements to build kernelshark and
then move it to another machine.

-- Steve

> 
> Suggested-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
> Signed-off-by: Yordan Karadzhov <ykaradzhov@vmware.com>
>
Yordan Karadzhov March 26, 2019, 1:35 p.m. UTC | #7
On 26.03.19 г. 14:58 ч., Steven Rostedt wrote:
> On Wed, 13 Mar 2019 17:22:18 +0200
> Yordan Karadzhov <ykaradzhov@vmware.com> wrote:
> 
>> The CMAKE build system of KernelShark performs automated search for the
>> trace-cmd libraries, headers and executable before building the GUI.
>> The new order of the list of directories to search in is the following:
>>
>> 1. ${TRACE_CMD}/  ($TRACE_CMD is an environment variable)
>>
>> 2. CMAKE_SOURCE_DIR/../
>>
>> 3. Platform / system specific locations
> 
> I'm still confused. We shouldn't be looking for any paths at build time.
> This should be done at run time.
> 
> Now, we can check the local directory that kernelshark lives in. That
> is, if we are running from a fresh build, at start up, we can look at
> 
>   `pwd`/../lib | `pwd`/../../plugins
> 
> and see if those directories exist at run time. And if they do, we can
> use them (as we would assume that the exec is running from a local
> source tree).
> 
> I really don't want any build artifacts in the executable. This will
> mean that you need to do special arrangements to build kernelshark and
> then move it to another machine.

I am confused. I do not know how we can make possible to build 
kernelshark on one machine and then move it to another machine and 
guarantee that it will work. Note that trace-cmd is not the only 
external dependency. We depend on OpenGL, Qt, ....

Qt itself depends on big number of things.

Is this really doable?
Y.

> 
> -- Steve
> 
>>
>> Suggested-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
>> Signed-off-by: Yordan Karadzhov <ykaradzhov@vmware.com>
>>
Steven Rostedt March 26, 2019, 1:57 p.m. UTC | #8
On Tue, 26 Mar 2019 15:35:28 +0200
"Yordan Karadzhov (VMware)" <y.karadz@gmail.com> wrote:

> > I really don't want any build artifacts in the executable. This will
> > mean that you need to do special arrangements to build kernelshark and
> > then move it to another machine.  
> 
> I am confused. I do not know how we can make possible to build 
> kernelshark on one machine and then move it to another machine and 
> guarantee that it will work. Note that trace-cmd is not the only 
> external dependency. We depend on OpenGL, Qt, ....
> 
> Qt itself depends on big number of things.
> 
> Is this really doable?

Yes, I've done it myself several times.

One only needs the "-dev" packages to build kernelshark. But if you
want to run it, you just need the normal packages. I have those
packages installed on several machines. In fact, I  may only want to
build kernelshark on one box, and then copy it to other boxes that
don't have the "-dev" packages.

There's also a case for cross compiling, where Qt, OpenGL and others
are already installed on those other boxes.

Package managers will let you know this is done all the time, right
Patrick? ;-)

-- Steve
Steven Rostedt March 26, 2019, 3:08 p.m. UTC | #9
On Tue, 26 Mar 2019 08:58:21 -0400
Steven Rostedt <rostedt@goodmis.org> wrote:

> I'm still confused. We shouldn't be looking for any paths at build time.
> This should be done at run time.
> 
> Now, we can check the local directory that kernelshark lives in. That
> is, if we are running from a fresh build, at start up, we can look at
> 
>  `pwd`/../lib | `pwd`/../../plugins
> 
> and see if those directories exist at run time. And if they do, we can
> use them (as we would assume that the exec is running from a local
> source tree).
> 
> I really don't want any build artifacts in the executable. This will
> mean that you need to do special arrangements to build kernelshark and
> then move it to another machine.

Note, I was confused as I was thinking this was about plugins and not
about the dynamic runtime / static libraries.

I see that this is about where to find those libraries. This is about
where to find libtracecmd (soon to be libftrace). Currently that's a
static library, and we want it to be a dynamic one in the future.

OK, I'm fine with this patch as is and will pull it in.


-- Steve
Patrick McLean March 27, 2019, 12:24 a.m. UTC | #10
On Tue, 26 Mar 2019 09:57:52 -0400
Steven Rostedt <rostedt@goodmis.org> wrote:

> On Tue, 26 Mar 2019 15:35:28 +0200
> "Yordan Karadzhov (VMware)" <y.karadz@gmail.com> wrote:
> 
> > > I really don't want any build artifacts in the executable. This
> > > will mean that you need to do special arrangements to build
> > > kernelshark and then move it to another machine.    
> > 
> > I am confused. I do not know how we can make possible to build 
> > kernelshark on one machine and then move it to another machine and 
> > guarantee that it will work. Note that trace-cmd is not the only 
> > external dependency. We depend on OpenGL, Qt, ....
> > 
> > Qt itself depends on big number of things.
> > 
> > Is this really doable?  
> 
> Yes, I've done it myself several times.
> 
> One only needs the "-dev" packages to build kernelshark. But if you
> want to run it, you just need the normal packages. I have those
> packages installed on several machines. In fact, I  may only want to
> build kernelshark on one box, and then copy it to other boxes that
> don't have the "-dev" packages.
> 
> There's also a case for cross compiling, where Qt, OpenGL and others
> are already installed on those other boxes.
> 
> Package managers will let you know this is done all the time, right
> Patrick? ;-)

This is pretty much how package managers operate, whenever you "apt-get
install" or "dnf install" the package manager is downloading binaries
built on a random server and installing them on your machine. As long
as the appropriate dependencies are installed (which the package
manager takes care of for you), it should just work.

Finding the libraries at runtime is generally taken care of by your
linker, and there is nothing that really needs to be done in your
package. For plugins (and other things that you dlopen()), you need to
come up with a way to figure out where to look. Most packages do this
with defaults defined at build time (packagers and distro security
teams will not like you very much if you hard code looking for dynamic
libraries at relative paths from the CWD), and overrides in
configuration files.
diff mbox series

Patch

diff --git a/kernel-shark/build/FindTraceCmd.cmake b/kernel-shark/build/FindTraceCmd.cmake
index fb2092a..b09a11b 100644
--- a/kernel-shark/build/FindTraceCmd.cmake
+++ b/kernel-shark/build/FindTraceCmd.cmake
@@ -14,17 +14,27 @@ 
 
 # MESSAGE(" Looking for trace-cmd ...")
 
+# First search in the user provided paths.
 find_path(TRACECMD_BIN_DIR      NAMES  trace-cmd
                                 PATHS  $ENV{TRACE_CMD}/tracecmd/
-                                       ${CMAKE_SOURCE_DIR}/../tracecmd/)
+                                       ${CMAKE_SOURCE_DIR}/../tracecmd/
+                                NO_DEFAULT_PATH)
 
 find_path(TRACECMD_INCLUDE_DIR  NAMES  trace-cmd.h
                                 PATHS  $ENV{TRACE_CMD}/include/trace-cmd/
-                                       ${CMAKE_SOURCE_DIR}/../include/trace-cmd/)
+                                       ${CMAKE_SOURCE_DIR}/../include/trace-cmd/
+                                NO_DEFAULT_PATH)
 
 find_path(TRACECMD_LIBRARY_DIR  NAMES  libtracecmd.a
                                 PATHS  $ENV{TRACE_CMD}/lib/trace-cmd/
-                                       ${CMAKE_SOURCE_DIR}/../lib/trace-cmd/)
+                                       ${CMAKE_SOURCE_DIR}/../lib/trace-cmd/
+                                NO_DEFAULT_PATH)
+
+# If not found, search in the default system paths. Note that if the previous
+# search was successful "find_path" will do nothing this time.
+find_path(TRACECMD_BIN_DIR      NAMES  trace-cmd)
+find_path(TRACECMD_INCLUDE_DIR  NAMES  trace-cmd.h)
+find_path(TRACECMD_LIBRARY_DIR  NAMES  libtracecmd.a)
 
 IF (TRACECMD_INCLUDE_DIR AND TRACECMD_LIBRARY_DIR)