| Message ID | 20190313152220.22026-2-ykaradzhov@vmware.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | Tuning the KernelShark build system | expand |
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.
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
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?
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
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.
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> >
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> >>
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
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
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 --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)
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(-)