-
Notifications
You must be signed in to change notification settings - Fork 989
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support Microsoft Symbol Server integration with Artifactory for Conan packages containing .pdb #4047
Comments
This is an amazing idea. But why just Windows? Linux has a similar feature. This video covers the basics. |
Doing this for linux would be great, but the approach may need to be different. I have not (yet?) figured out if One option would be to use
This would be the minimum viable product on windows (no need for a server, you download to a local path manually) and it would also help with linux. The command could also embed some of the needed logic to reproduce the build-id based paths in the target location (per-debugging format). This would require conan packages to track internally the files that are "debug" information, which I have no clue how complicated it would be to implement (I have never looked at the conan sources) |
@AliAskari cool -- I've raised #4056 "Support Linux stripped symbol debugging" @dribeas I'm sure there's a work-around using a conan command, but that's not the integration I'm requesting in this ticket. I think it's possible to reduce the number of steps for lusers^H^H^H^H^H^Hdevelopers. |
Have also raised: https://www.jfrog.com/jira/plugins/servlet/mobile#issue/RTFACT-18260 "Support Microsoft Symbol Server integration with Artifactory for Conan packages containing .pdb" to flag it to the Artifactory team. |
@michaelmaguire this issue does not appear to get the attention that (I think) it deserves. What are you currently doing to ensure that you have debuginfo for your packages? |
Right now we have a separate Microsoft symbol server set up, to which we upload symbols in our promotion builds. Sadly it's a completely parallel system, with a separate lifetime for packages. We've also started giving up on a solution here and switching more to use /Z7 https://docs.microsoft.com/en-us/cpp/build/reference/z7-zi-zi-debug-information-format?view=msvc-170 |
This is also what my team has done, but we aren't happy with this workaround. |
The solution that works just right now: the same as @michaelmaguire mentioned - uploading PDB-s from Conan packages to the separate symbol server on SMB file share; we have "syncing" script that unpacks Conan binary package The solution we are dreaming of: the separate service that implements SSQP protocol and works like an "indexer": it iterates over every PDB in every binary package in Artifactory instance, and stores the mapping from PDBs |
We would like to ensure that developers can debug production Windows software published internally using Conan.
We understand how we could publish libraries used in building our executable up to Conan and our pdb files separately to a symbol server accessible to VisualStudio.
However, given space constraints, we must manage the garbage collection of old library builds once we become certain they are no longer needed.
If we store .pdb files to a separate symbol server, then whatever lifecycle and deprecation management we decide on for Conan packages must be duplicated for the management of the symbol server pdbs.
If instead we could simply publish the pdb and lib files in the same Conan package, publish them to Artifactory and aim Visual Studio at the artifactory conan repo as a Symbol Server, we could manage those artifacts together.
Can we please request a Conan/Artifactory integration enhancement that would allow .pdb files published within Conan packages to be transparently available as if it were a Symbol Server, using the usual hash query mechanism implemented by Symbol Servers https://stackoverflow.com/questions/1419347/microsoft-symbol-server-local-cache-hash-algorithm ?
I have raised: https://www.jfrog.com/jira/browse/RTFACT-18260 in the Artifactory JIRA.
To help us debug your issue please explain:
The text was updated successfully, but these errors were encountered: