[bug] Debug package source path set incorrectly

[cubisttriangle]

Environment details

• Operating System+version: Win11 21H2
• Compiler+version: msvc v193
• Conan version: 2.0.4
• Python version: 3.11.0

I am trying to use a debugger to step into a conan package (ffmpeg on windows). To do this, I create a debug version of the package and use the debug configuration in the build. When I attempt to step into the package, its seems like it has the symbols, but the source code location is incorrectly set to the temp file location, rather than the actual package source location. Maybe this is a bug?

Visual Studio lets me know that the source file it's expecting to find in the temp folder (.conan2/p/t/ffmpe...) cannot be found and prompts for the correct location. I can then use conan cache path --folder source ffmpeg/$VERSION to get the location to sources the debugger can use. At this point I can debug regularly

Steps to reproduce

1. Use conan2
2. Build and install debug version of ffmpeg to conan cache
3. Add dependency to on ffmpeg to visual studio project using MSBuildDeps generator (need to add the path to the generated conan_ffmpeg.props file in .vcxproj file for appropriate configurations)
4. Set visual studio solution configuration to Debug
5. Add break point somewhere and attempt to step into ffmpeg

Logs

No response

[memsharded]

Hi @cubisttriangle

Thanks for your report.

The first thing that we should check is if it is something specific to ffmpeg recipe, or to the Conan build system integrations.
Could you please give it a try with other recipe? I'd recommend using conan new cmake_lib -d name=pkg -d version=0.1, put it as a dependency in your project and try the same.

I suspect that it will still happen, but useful to rule out the ffmepg recipe from the equation.
I think this could be related to the movement of the final build directory when the package is built and the package-revision can be computed. Could you please also try defining the no_copy_source=True as an attribute in the test pkg recipe? I think that should work.

[cubisttriangle]

@memsharded thanks for the response!

I did lots of builds yesterday trying to see what was going on, but I'm having trouble putting together the pieces. One thing I noticed is that I am only able to step into ffmpeg when I specify the option, ffmpeg/*:shared=False. I am not able to debug when linking dynamically.

When I tried to reproduce the issue with a basic package using the command you provided, I was unable to step into that package's source. It didn't matter whether I was linking statically or dynamically. This is true of other packages I've been trying too. Ironically, I've only been able to step into ffmpeg. That said, I do see .pdb files in the conan cache.

I am also unclear on whether build results should differ when I use the conanfile.py in the pkg directory or when I specify pkg as dependency and build via --build=missing. Should debugging be possible in one case and not the other, or should it be the same? During the builds, I was also using the following flags -s:b build_type=Debug -s:h build_type=Debug.

[cubisttriangle]

Regarding the no_copy_source flag:

I added no_copy_source = True to the ffmpeg conanfile.py, then packaged a debug build. I can confirm that this fixes the source file location for the debugger. Yay - good idea! Next, I attempted to do a release build, but one of patch steps failed since the file had been patched previously during the debug build. This could be handled in ffmpeg's conanfile.py, so I don't think it's a big deal, but thought I'd mention it.

I could imagine it getting more complicated for auto-generated source.

[cubisttriangle]

Regarding the no_copy_source flag:

I added no_copy_source = True to the ffmpeg conanfile.py, then packaged a debug build. I can confirm that this fixes the source file location for the debugger. Yay - good idea! Next, I attempted to do a release build, but one of patch steps failed since the file had been patched previously during the debug build. This could be handled in ffmpeg's conanfile.py, so I don't think it's a big deal, but thought I'd mention it.

I could imagine it getting more complicated for auto-generated source.

I now see it is required that the source directory not be modified when this flag is specified.

[memsharded]

Yes, that is true, the source() must be common to all different binaries, so if there are specific per-configuration patches then it is not possible to optimize with no_copy_sources=True, and a full copy to the "build-folder" before patching is necessary. But this "build-folder" is relocated together with the final package once the package is built, to the final location corresponding to the package-revision.

I will take this for brainstorming with the team, not sure what can be done, but lets try.

Side note: ConanCenter recipes, by default, they do not package the *.pdb files in Windows, which is necessary to step-into. I am adding

def package(self):
    ...
    copy(self, "*.pdb", self.build_folder, os.path.join(self.package_folder, "lib"), keep_path=False)

[cubisttriangle]

Yes, that is true, the source() must be common to all different binaries, so if there are specific per-configuration patches then it is not possible to optimize with no_copy_sources=True, and a full copy to the "build-folder" before patching is necessary. But this "build-folder" is relocated together with the final package once the package is built, to the final location corresponding to the package-revision.

I will take this for brainstorming with the team, not sure what can be done, but lets try.

Side note: ConanCenter recipes, by default, they do not package the *.pdb files in Windows, which is necessary to step-into. I am adding

def package(self):
    ...
    copy(self, "*.pdb", self.build_folder, os.path.join(self.package_folder, "lib"), keep_path=False)

After adding the line you mentioned in the package function, I am able to step into the package's source code. It has the same issue with the source code path, which I can now overcome in most cases with no_copy_sources=True.

Thanks!

[memsharded]

Thanks to you for your feedback. Happy to know that with those tips it can be done in most cases.
I am doing an experiment in #13810 to use as a base for discussion with the team, lets see how it goes.

Also, for some advanced use cases, to debug your own (not ConanCenter) recipes, getting the recipe in user space and putting it in editable mode could help to handle cases where you need to also modify the sources of the dependency. The editable needs a correct definition of layout() to support it (ConanCenter recipes do not implement it), but might be worth exploring it too.

[memsharded]

Fixed in #13833, from Conan 2.0.5, packages built in the local cache with --build, will be possible to debug and step-into, because they will not be relocated.