Command that fetches sources for debugging

[da2r-20]

I have an executable built with packages in Debug configuration.
I want to debug the exe on a remote machine.
I want to have sources so I can have a better debugging experience.

Is it possible to install a package's sources only?
I know that conan install <package-name> -s build_type=Debug --build fetches the code but also builds it.

---

• I've read the CONTRIBUTING guide.
• I've specified the Conan version, operating system version and any tool that can be relevant.
• I've explained the steps to reproduce the error or the motivation/use case of the question/suggestion.

[lasote]

Hi @doronAtuar! Thanks for asking.

We have the conan source command, but it requires a path to the recipe and usually is only used while you are developing the recipe, to test that you can fetch the sources correctly. Would be nice to learn about your use case, because improving the debugging is in our roadmap, so we could think about a feature if it helps!

Which debugger/oss are you trying to use? Linux gdb, lldb, Windows...
Would it be useful for you to get the sources to a local directory? (not in the cache)
How would you use the sources with the debugger?
In general, how would be the debugging process? From the packages using the dependencies or with a "test" executable or...

[da2r-20]

Which debugger/oss are you trying to use? Linux gdb, lldb, Windows...

I'm using gdb on Linux but I think my use case is alo valid for lldb.

I'm compiling my Debug version on one machine.
Symbols of my dependancies are attached to source files in my Conan cache.

In-order to get source shown on gdb at the target machine I need to have the sources at the same path as the compilation machine.

Would it be useful for you to get the sources to a local directory? (not in the cache).

So yes, It's better if they are at the cache folder.

How would you use the sources with the debugger?

Once they are there you don't need to do anything. gdb will find them and load them.

In general, how would be the debugging process? From the packages using the dependencies or with a "test" executable or...

I'm not sure I understand the question correctly.
But the way I debug then is attach gdb to the process or run the process with gdb and then
debug regularly as I do on a local machine.

The whole process can be achieved without Conan by:

• Redirecting gdb source paths to the sources location
• Copying/cloning sources manually of the correct tag.
• May require git, access tokens to the git server.

The problem is that it may require extra installations, tokens for git server, cloning the right tag.
The process is quite manual so very error prone.

I've already managed to do all that with the
conan install <package-name> -s build_type=Debug --build command.
The build fails but... it puts the sources exactly where I want them.

[lasote]

Thanks for the answer, you explained exactly what I need.
Some time ago I made some test with gdb, that appears to be the only one that supported the flow I was trying to achieve:

• Getting the sources of a package, even in a different computer/local cache folder. I don't recall if I developed a new command/parameter or I did like you with conan install --build.
• I created a generator of a gdbinit file, so the sources in the new cache directory were mapped to the old ones.

It more or less worked, but I had some issues I don't exactly recall. Also, I can remember that I wasn't able to do it with llvm because the ini file doesn't work like that and also I neither made it work in Windows with visual studio, where the pdbs are necessary.

So, we don't have yet a way to only download the sources but I add this issue to a new "debugging" project so we can have the requirement and use case present when we develop the solution.

[memsharded]

An important thing to recall here is the difference between the "initial" source files and the "build" source files that are the ones that we need to debug. This is the scenario:

• A recipe source() method does a git clone of some repo
• The build() method has typical autotools with some configure step, which actually creates a config.h file on the fly with some definitions.
• It seems it would be necessary to package those sources, including the config.h, in the package() step, so when we debug, it is stepping into the sources actually used in the build. Same would happen to other files dynamically generated during the build (e.g. stubs from running protoc on some .proto files for protobuf).

So the open question would be:

• Are we good enough by retrieving the "initial" sources to debug, or we need to debug with the exact sources used to build?

[da2r-20]

Hi @memsharded,
From my experience I haven't had the need to debug auto generated files(protoc stubs, QT moc ui etc.)

But I'm sure the use-case exists out there.
Especially if you are developing a project that it's role is to generate such files.

You could make users that want debug sources to build the package on the target machine.
Solving the problem for people that want auto generated files debugging.
But it may require extra installations on a target machine. (version control, dev dependencies)

[sourcedelica]

We have a similar need.

I would have a conanfile.txt from a particular revision in Git. The sources that comprise that app would be the sources for the current executable plus the sources from the dependencies from conanfile.txt. Ultimately we would want to use the workspaces feature of Conan too, so that would determine where sources came from.

What we would need from Conan is a list of source directories for a GDB source path.

This feature could also be part of an IDE integration. In the Java world your application is defined by a configuration file that says which packages the application uses (a .pom file defines the .jar files that are used). The source for your application is the source of the current app plus the source from the .jar files. When you navigate to a class that is in a .jar file it pulls the source from the local package (Maven) cache. It's a seamless experience that is very productive.

[Lizabeth-Roberts-Bose]

I just wanted to add to this conversation by saying that this is a feature I would highly like to see also.

In my use case, I am using an environment and IDE that is provided to us by a third party vendor we don't have control over, and in order to debug code it requires source code from each dependency.

If there was a Conan command that I could run, something like conan source --get-all that would grab all the sources in the requirements for the current recipe that would be amazing and very useful. It would also probably be a requirement to be able to output a JSON file with the locations in cache of those source directories. Similar to conan info

[memsharded]

Conan 2.0 beta9 is finally getting a new way of getting sources of all dependencies: #13003

This will allow forcing the source() method even for conan graph info command, and as conf can be applied per-package, it can be used to force the source() of individual packages if desired.
Gathering the sources will be straightforward with a custom new deployer that iterates dep.source_folder, and doing whatever is necessary for the debugger (this could be another feature, but this ticket is about fetching the sources, which should be covered)

So I am closing this ticket as implemented for 2.0b9, please try when released, thanks!