Allowed dependencies in CUDADataFormats?

[davidlange6]

CUDADataFormats has a dependency on GeometryTrackerGeometryBuilder, which depends on lots of other things. I would have assumed that CUDADataFormats had similar dependency requirements to DataFormats? If not, how are we designing the dependency evolution in this area?

[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

[makortel]

assign core, heterogeneous

[cmsbuild]

New categories assigned: heterogeneous,core

@Dr15Jones,@smuzaffar,@makortel,@makortel,@fwyzard you have been requested to review this Pull request/Issue and eventually sign? Thanks

[makortel]

I think we're in a process of figuring out the dependence rules (by trial and error).

The CUDADataFormats is a bit special because all the classes are intended to be transient only. The current documentation has

Your package may be dependent on other CMSSW packages outside of the subsystems devoted to product definitions

which is (partially) why the dependence on Geometry hasn't raised red flags so far.

In practice only the Geometry/TrackerGeometryBuilder/interface/phase1PixelTopology.h is being #included, and that header only defines bunch of constants and functions and a struct using those constants, without any dependence on other code in Geometry/TrackerNumberingBuilder, and technically the phase1PixelTopology.h could be easily moved elsewhere. Issue #32483 looks like a good place to discuss this route further.

I presume the dependence on Geometry causes headache for the C++ modules, right? What about transient products declared in non-DataFormat packages that depend on Geometry packages?

[davidlange6]

On Apr 5, 2021, at 7:01 PM, Matti Kortelainen ***@***.***> wrote: I think we're in a process of figuring out the dependence rules (by trial and error). The CUDADataFormats is a bit special because all the classes are intended to be transient only. The current documentation has Your package may be dependent on other CMSSW packages outside of the subsystems devoted to product definitions which is (partially) why the dependence on Geometry hasn't raised red flags so far. In practice only the Geometry/TrackerGeometryBuilder/interface/phase1PixelTopology.h is being #included, and that header only defines bunch of constants and functions and a struct using those constants, without any dependence on other code in Geometry/TrackerNumberingBuilder, and technically the phase1PixelTopology.h could be easily moved elsewhere. Issue #32483 looks like a good place to discuss this route further. I presume the dependence on Geometry causes headache for the C++ modules, right? What about transient products declared in non-DataFormat packages that depend on Geometry packages?

It does not today, no. There is the issue of transient vs persistent, but there is also the issue of managing and understanding the plan for a hierarchical dependency chain, which is what prompted the question. Anyway, sounds like there is an easy fix to this one. I’ll read up on #32483

…

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.