[PATCH v2 0/3] Tuning the KernelShark build system

[PATCH v2 0/3] Tuning the KernelShark build system

[Yordan Karadzhov]

This patch set combines few minor tweaks of the KernelShark build
system default configurations suggested by Steven.

Changes in v2:
  - The default location of the cached configuration is now
${HOME}.cache/kernelshark

  - KsMainWindow::lastSessionFile was made public, because we will
used it later when loading the Last Session directly from the command line.

Yordan Karadzhov (3):
  kernel-shark: Reorder the priority when searching for trace-cmd libs
  kernel-shark: Configuration information in ${HOME}/.cache/kernelshark
  kernel-shark: Set the configuration cache directory via env. variable

 Makefile                              |  2 +-
 kernel-shark/CMakeLists.txt           | 13 ++++++++-----
 kernel-shark/build/FindTraceCmd.cmake | 16 +++++++++++++---
 kernel-shark/build/deff.h.cmake       |  4 ++--
 kernel-shark/src/KsMainWindow.cpp     | 20 +++++++++++++-------
 kernel-shark/src/KsMainWindow.hpp     |  2 ++
 6 files changed, 39 insertions(+), 18 deletions(-)

-- 
2.19.1

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

[Yordan Karadzhov]

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(-)

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)
 
-- 
2.19.1

[PATCH v2 2/3] kernel-shark: Configuration information in ${HOME}/.cache/kernelshark

[Yordan Karadzhov]

By default the "Last session" configuration file will be saved in
${HOME}/.cache/kernelshark

After applying this patch you may need to clean the CMAKE cache.
This can be done by:

    cd kernel-shark/build/;./cmake_clean.sh; cd -
    make gui

Suggested-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Yordan Karadzhov <ykaradzhov@vmware.com>
---
 Makefile                          |  2 +-
 kernel-shark/CMakeLists.txt       | 13 ++++++++-----
 kernel-shark/build/deff.h.cmake   |  4 ++--
 kernel-shark/src/KsMainWindow.cpp |  4 ++--
 4 files changed, 13 insertions(+), 10 deletions(-)

diff --git a/Makefile b/Makefile
index b780718..4cebd00 100644
--- a/Makefile
+++ b/Makefile
@@ -254,7 +254,7 @@ all_cmd: $(CMD_TARGETS)
 CMAKE_COMMAND = /usr/bin/cmake
 
 $(kshark-dir)/build/Makefile: $(kshark-dir)/CMakeLists.txt
-	$(Q) cd $(kshark-dir)/build && $(CMAKE_COMMAND) ..
+	$(Q) cd $(kshark-dir)/build && $(CMAKE_COMMAND) -DKS_CACHE_DIR=$(HOME)/.cache/kernelshark ..
 
 gui: force $(CMD_TARGETS) $(kshark-dir)/build/Makefile
 	$(Q)$(MAKE) $(S) -C $(kshark-dir)/build
diff --git a/kernel-shark/CMakeLists.txt b/kernel-shark/CMakeLists.txt
index 20ced14..c3743b4 100644
--- a/kernel-shark/CMakeLists.txt
+++ b/kernel-shark/CMakeLists.txt
@@ -12,10 +12,12 @@ message("\n project: Kernel Shark: (version: ${KS_VERSION_STRING})\n")
 
 set(KS_DIR ${CMAKE_SOURCE_DIR})
 
-# Make a directory to hold configuration files. To change this do:
-# cmake .. -DKS_CONF_DIR=/your/preferred/path
-set(KS_CONF_DIR "${KS_DIR}/.ksconf" CACHE STRING "Directory for configuration files.")
-file(MAKE_DIRECTORY ${KS_CONF_DIR})
+# Make a directory to hold cached configuration files. To change this do:
+# cmake .. -DKS_CACHE_DIR=/your/preferred/path
+set(KS_CACHE_DIR "$ENV{HOME}/.cache/kernelshark"
+    CACHE STRING "Directory for cached configuration files.")
+
+file(MAKE_DIRECTORY ${KS_CACHE_DIR})
 
 include(${KS_DIR}/build/FindTraceCmd.cmake)
 include(${KS_DIR}/build/FindJSONC.cmake)
@@ -59,7 +61,8 @@ include_directories(${KS_DIR}/src/
 message("")
 message(STATUS "C flags      : " ${CMAKE_C_FLAGS})
 message(STATUS "CXX flags    : " ${CMAKE_CXX_FLAGS})
-message(STATUS "Linker flags : " ${CMAKE_EXE_LINKER_FLAGS})
+message(STATUS "Linker flags : " ${CMAKE_EXE_LINKER_FLAGS}\n)
+message(STATUS "config. files saved in ${KS_CACHE_DIR}")
 
 add_subdirectory(${KS_DIR}/src)
 add_subdirectory(${KS_DIR}/examples)
diff --git a/kernel-shark/build/deff.h.cmake b/kernel-shark/build/deff.h.cmake
index 80d624c..56b37da 100644
--- a/kernel-shark/build/deff.h.cmake
+++ b/kernel-shark/build/deff.h.cmake
@@ -14,8 +14,8 @@
 /** KernelShark source code path. */
 #cmakedefine KS_DIR "@KS_DIR@"
 
-/** KernelShark configuration directory path. */
-#cmakedefine KS_CONF_DIR "@KS_CONF_DIR@"
+/** KernelShark cache directory path. */
+#cmakedefine KS_CACHE_DIR "@KS_CACHE_DIR@"
 
 /** Location of the trace-cmd executable. */
 #cmakedefine TRACECMD_BIN_DIR "@TRACECMD_BIN_DIR@"
diff --git a/kernel-shark/src/KsMainWindow.cpp b/kernel-shark/src/KsMainWindow.cpp
index 8ac19a7..d832f3f 100644
--- a/kernel-shark/src/KsMainWindow.cpp
+++ b/kernel-shark/src/KsMainWindow.cpp
@@ -133,7 +133,7 @@ KsMainWindow::KsMainWindow(QWidget *parent)
 KsMainWindow::~KsMainWindow()
 {
 	kshark_context *kshark_ctx(nullptr);
-	QString file = KS_CONF_DIR;
+	QString file = KS_CACHE_DIR;
 
 	file += "/lastsession.json";
 
@@ -370,7 +370,7 @@ void KsMainWindow::_open()
 
 void KsMainWindow::_restorSession()
 {
-	QString file = KS_CONF_DIR;
+	QString file = KS_CACHE_DIR;
 	file += "/lastsession.json";
 
 	loadSession(file);
-- 
2.19.1

[PATCH v2 3/3] kernel-shark: Set the configuration cache directory via env. variable

[Yordan Karadzhov]

The environment variable ${KS_USER_CONF_DIR} can be used to specify
the directory where the "Last session" configuration file will be
saved.

Suggested-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Yordan Karadzhov <ykaradzhov@vmware.com>
---
 kernel-shark/src/KsMainWindow.cpp | 20 +++++++++++++-------
 kernel-shark/src/KsMainWindow.hpp |  2 ++
 2 files changed, 15 insertions(+), 7 deletions(-)

diff --git a/kernel-shark/src/KsMainWindow.cpp b/kernel-shark/src/KsMainWindow.cpp
index d832f3f..a92944e 100644
--- a/kernel-shark/src/KsMainWindow.cpp
+++ b/kernel-shark/src/KsMainWindow.cpp
@@ -133,9 +133,7 @@ KsMainWindow::KsMainWindow(QWidget *parent)
 KsMainWindow::~KsMainWindow()
 {
 	kshark_context *kshark_ctx(nullptr);
-	QString file = KS_CACHE_DIR;
-
-	file += "/lastsession.json";
+	QString file = lastSessionFile();
 
 	_updateSession();
 	kshark_save_config_file(file.toLocal8Bit().data(),
@@ -368,12 +366,20 @@ void KsMainWindow::_open()
 		loadDataFile(fileName);
 }
 
-void KsMainWindow::_restorSession()
+/** Get the description file of the last session. */
+QString KsMainWindow::lastSessionFile()
 {
-	QString file = KS_CACHE_DIR;
-	file += "/lastsession.json";
+	const char *file = getenv("KS_USER_CONF_DIR");
 
-	loadSession(file);
+	if (!file)
+		file = KS_CACHE_DIR;
+
+	return QString(file) +  "/lastsession.json";
+}
+
+void KsMainWindow::_restorSession()
+{
+	loadSession(lastSessionFile());
 	_graph.updateGeom();
 }
 
diff --git a/kernel-shark/src/KsMainWindow.hpp b/kernel-shark/src/KsMainWindow.hpp
index a93382a..c479520 100644
--- a/kernel-shark/src/KsMainWindow.hpp
+++ b/kernel-shark/src/KsMainWindow.hpp
@@ -37,6 +37,8 @@ public:
 
 	void loadSession(const QString &fileName);
 
+	QString lastSessionFile();
+
 	/**
 	 * @brief
 	 *
-- 
2.19.1

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

[Patrick McLean]

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.

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

[Steven Rostedt]

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

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

[Patrick McLean]

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?

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

[Steven Rostedt]

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

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

[Patrick McLean]

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.

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

[Steven Rostedt]

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

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

[Yordan Karadzhov (VMware)]

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

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

[Steven Rostedt]

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

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

[Steven Rostedt]

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

Re: [PATCH v2 2/3] kernel-shark: Configuration information in ${HOME}/.cache/kernelshark

[Steven Rostedt]

On Wed, 13 Mar 2019 17:22:19 +0200
Yordan Karadzhov <ykaradzhov@vmware.com> wrote:

> @@ -12,10 +12,12 @@ message("\n project: Kernel Shark: (version: ${KS_VERSION_STRING})\n")
>  
>  set(KS_DIR ${CMAKE_SOURCE_DIR})
>  
> -# Make a directory to hold configuration files. To change this do:
> -# cmake .. -DKS_CONF_DIR=/your/preferred/path
> -set(KS_CONF_DIR "${KS_DIR}/.ksconf" CACHE STRING "Directory for configuration files.")
> -file(MAKE_DIRECTORY ${KS_CONF_DIR})
> +# Make a directory to hold cached configuration files. To change this do:
> +# cmake .. -DKS_CACHE_DIR=/your/preferred/path
> +set(KS_CACHE_DIR "$ENV{HOME}/.cache/kernelshark"
> +    CACHE STRING "Directory for cached configuration files.")
> +
> +file(MAKE_DIRECTORY ${KS_CACHE_DIR})
>  

This time I'm not confused (I tried it out).

The build process should *not* make the .cache/kernelshark directory.
It should be made by the application, just like all other applications
do.

-- Steve

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

[Patrick McLean]

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.

Re: [PATCH v2 2/3] kernel-shark: Configuration information in ${HOME}/.cache/kernelshark

[Yordan Karadzhov]

On 26.03.19 г. 22:51 ч., Steven Rostedt wrote:
> On Wed, 13 Mar 2019 17:22:19 +0200
> Yordan Karadzhov <ykaradzhov@vmware.com> wrote:
> 
>> @@ -12,10 +12,12 @@ message("\n project: Kernel Shark: (version: ${KS_VERSION_STRING})\n")
>>   
>>   set(KS_DIR ${CMAKE_SOURCE_DIR})
>>   
>> -# Make a directory to hold configuration files. To change this do:
>> -# cmake .. -DKS_CONF_DIR=/your/preferred/path
>> -set(KS_CONF_DIR "${KS_DIR}/.ksconf" CACHE STRING "Directory for configuration files.")
>> -file(MAKE_DIRECTORY ${KS_CONF_DIR})
>> +# Make a directory to hold cached configuration files. To change this do:
>> +# cmake .. -DKS_CACHE_DIR=/your/preferred/path
>> +set(KS_CACHE_DIR "$ENV{HOME}/.cache/kernelshark"
>> +    CACHE STRING "Directory for cached configuration files.")
>> +
>> +file(MAKE_DIRECTORY ${KS_CACHE_DIR})
>>   
> 
> This time I'm not confused (I tried it out).
> 
> The build process should *not* make the .cache/kernelshark directory.
> It should be made by the application, just like all other applications
> do.
> 

Yes, this makes sense. I will make the application creating the 
.cache/kernelshark directory if it doesn't exist.

But do I need to remove the creation of directory in the build process?

Thanks!
Yordan


> -- Steve
> 

Re: [PATCH v2 2/3] kernel-shark: Configuration information in ${HOME}/.cache/kernelshark

[Steven Rostedt]

On Wed, 27 Mar 2019 08:58:20 +0000
Yordan Karadzhov <ykaradzhov@vmware.com> wrote:

> Yes, this makes sense. I will make the application creating the 
> .cache/kernelshark directory if it doesn't exist.
> 
> But do I need to remove the creation of directory in the build process?

Yes, please remove it. A build process shouldn't modify directories
outside the build directory unless specifically told to do so (like
make install).

-- Steve