While working in the Cabal codebase, I noticed that we repeatedly want to treat these types as interconvertible: ComponentName, Component, ComponentLocalBuildInfo. There are two problems:
- We keep doing goofy things like use the
ComponentName to get the Component, then throw it out and later retrieve the Component again. Each of these is a linear scan over the components of the package description! So everything is inconvenient forever. Or we have finally gotten to a ComponentLocalBuildInfo, but then we want the ComponentName again.
- It's not right in the Backpack world to treat
ComponentLocalBuildInfo as interchangeable with ComponentName; the same component might get built multiple times.
BuildTarget goes through the trouble of getting out a module/filename that specifically was requested, at which point it is promptly discarded.
So, I propose we create a new data structure to bundle together Component, ComponentLocalBuildInfo, and the file target, and then consistently apply it to all functions in LocalBuildInfo right now. Let's call it TargetInfo. For example, componentsInBuildOrder can now get a new variant targetsInBuildOrder which deals in TargetInfos rather than ComponentLocalBuildInfos.
I think this should have minimal BC concerns, because it is an easy matter to keep all the old functions around.
While working in the Cabal codebase, I noticed that we repeatedly want to treat these types as interconvertible:
ComponentName,Component,ComponentLocalBuildInfo. There are two problems:ComponentNameto get theComponent, then throw it out and later retrieve theComponentagain. Each of these is a linear scan over the components of the package description! So everything is inconvenient forever. Or we have finally gotten to aComponentLocalBuildInfo, but then we want the ComponentName again.ComponentLocalBuildInfoas interchangeable withComponentName; the same component might get built multiple times.BuildTargetgoes through the trouble of getting out a module/filename that specifically was requested, at which point it is promptly discarded.So, I propose we create a new data structure to bundle together
Component,ComponentLocalBuildInfo, and the file target, and then consistently apply it to all functions inLocalBuildInforight now. Let's call itTargetInfo. For example,componentsInBuildOrdercan now get a new varianttargetsInBuildOrderwhich deals inTargetInfos rather thanComponentLocalBuildInfos.I think this should have minimal BC concerns, because it is an easy matter to keep all the old functions around.