Preferred way to break DataFormats/TrackReco and DataFormats/TrackCandidate circle?

[davidlange6]

There is a ~trivially fixed circular dependency between DataFormats/TrackReco and DataFormats/TrackCandidate. Which package is meant to depend on the other. I can move things accordingly (either some dictionaries that use classes from both packages or one header)

[cmsbuild]

A new Issue was created by @davidlange6 David Lange.

@Dr15Jones, @dpiparo, @silviodonato, @smuzaffar, @makortel, @qliphy can you please review it and eventually sign/assign? Thanks.

cms-bot commands are listed here

[davidlange6]

assign reconstruction

[cmsbuild]

New categories assigned: reconstruction

@slava77,@perrotta,@jpata you have been requested to review this Pull request/Issue and eventually sign? Thanks

[slava77]

@davidlange6
I'm missing details or being confused by the phrasing (perhaps as trivial as a question mark in the "Which package is meant to depend on the other.")

[slava77]

after looking a bit more, I see that the direct dependence of TrackReco on TrackCandidate is only in the dictionaries definition in classes.h used for an aggregate <TrackCandidate, Track> definition.

The dependence of TrackCandidate is apparently via
DataFormats/TrackCandidate/interface/TrackCandidate.h:
#include "DataFormats/TrackReco/interface/TrajectoryStopReasons.h"

@davidlange6
please clarify if this is what you meant with the issue description.

[davidlange6]

Yes, that sentence misses a question mark. Would we like DataFormats/TrackReco to depend on DataFormats/TrackCandidate or would we like DataFormats/TrackCandidate to depend on DataFormats/TrackReco? On Aug 31, 2020, at 2:50 PM, Slava Krutelyov <notifications@github.com<mailto:notifications@github.com>> wrote: @davidlange6<https://github.com/davidlange6> I'm missing details or being confused by the phrasing (perhaps as trivial as a question mark in the "Which package is meant to depend on the other.") — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#31301 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABGPFQ3KHEN7YROFOTROORDSDOL7VANCNFSM4QQPAVCA>.

[slava77]

@mtosi @vmariani

@rovere
it looks like you are the original developer and perhaps recall the history.

Naively, it looks to me that DataFormats/TrackReco/interface/TrajectoryStopReasons.h can be moved to DataFormats/TrackCandidate/interface/

[davidlange6]

Yes, thats all correct. On Aug 31, 2020, at 3:01 PM, Slava Krutelyov <notifications@github.com<mailto:notifications@github.com>> wrote: after looking a bit more, I see that the direct dependence of TrackReco on TrackCandidate is only in the dictionaries definition in classes.h used for an aggregate <TrackCandidate, Track> definition. The dependence of TrackCandidate is apparently via DataFormats/TrackCandidate/interface/TrackCandidate.h: #include "DataFormats/TrackReco/interface/TrajectoryStopReasons.h" @davidlange6<https://github.com/davidlange6> please clarify if this is what you meant with the issue description. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#31301 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABGPFQ6NHONULXTSIOFILADSDONLZANCNFSM4QQPAVCA>.

[rovere]

@mtosi @vmariani

@rovere
it looks like you are the original developer and perhaps recall the history.

Naively, it looks to me that DataFormats/TrackReco/interface/TrajectoryStopReasons.h can be moved to DataFormats/TrackCandidate/interface/

From a quick look, I tend to agree on that. That would also imply to move the corresponding *cc.

[slava77]

FWIW, TrajectoryStopReasons is actually a track candidate stop reason.
So, the relocation seems reasonable.

[slava77]

+1

fixed in #31327 (merged Sept 3)
the dependency cycle is gone, according to the ignominy report in https://cmssdt.cern.ch/SDT/cgi-bin/newQA.py?arch=slc7_amd64_gcc820&release=CMSSW_11_2_X_2020-09-04-2300

[cmsbuild]

This issue is fully signed and ready to be closed.