Reputation: 3739
Typically Conan package contains only build artifacts like *.dll
, *.lib
, *.pdb
, *.so
, *.a
, *.dylib
files as well headers of given C or C++ library. However sometimes when you debugging your code consuming the library is very useful to be able to step into the library code to look what happens inside. For example to determine when having some problem whether this is because of incorrect use of the library or because of bug in it.
Upvotes: 7
Views: 4325
Reputation: 5972
There are two strategies that might work to debug dependencies:
--build=PkgName
argument. When you build from sources the package, depending on the build system, it is possible that the binary artifacts reference the temporary build folder where the package was built, and then be able to find them and use the to debug. This strategy can work for third party packages, even when they do not consider debug.With gdb
you could do something like
def build(self):
cmake = CMake(self.settings)
gcc_dbg_src = ""
if self.settings.compiler == "gcc" and self.settings.build_type == "Debug":
gcc_dbg_src = ' -DCMAKE_CXX_FLAGS="-fdebug-prefix-map=%s/hello=src"' % os.getcwd()
self.run('cmake hello %s %s' % (cmake.command_line, gcc_dbg_src))
self.run("cmake --build . %s" % cmake.build_config)
def package(self):
self.copy("*.h", dst="include", src="hello")
if self.settings.build_type == "Debug":
self.copy("*.cpp", dst="src", src="hello")
self.copy("*.lib", dst="lib", keep_path=False)
self.copy("*.a", dst="lib", keep_path=False)
To make sure that you compile with the right flags, and also that the source files are packaged too. Then, in the consumer side, you might want to imports
the .cpp
files, so the gdb
debugger can find them besides the binary being debug, or play with your debugger path to add the package folder.
In Windows, with Visual Studio, you probably want to package the .pdb
files
Upvotes: 6