search for: imaginged

...; > Originally InputFiles was the abstract interface that he Resolver used to > see all the inputs. If InputGraph supported the methods > forEachInitalAtom() and searchLibraries() then we could get rid of > InputFiles and have the Resolver uses InputGraph directly. > This is how I imaginged it would work. - Michael Spencer > > What should the interface be that the Resolver uses for handling groups? > > -Nick > > On Sep 4, 2013, at 1:42 PM, Shankar Easwaran <shankare at codeaurora.org> > wrote: > > > Hi, > > > > With the inputGraph now...

I do think we have too many classes. I thought InputGraph was going to replace InputFiles. It seems link LinkerInput could be merged into FileNode. Originally InputFiles was the abstract interface that he Resolver used to see all the inputs. If InputGraph supported the methods forEachInitalAtom() and searchLibraries() then we could get rid of InputFiles and have the Resolver uses InputGraph

Hi, With the inputGraph now, lld models command line options, input files as nodes in the InputGraph called InputElements. In the current approach, each InputElement is converted to a LinkerInput, which works if all lld deals with individual files. Dealing with ControlNodes (Groups), have a problem with it, on how to model that as a LinkerInput. Joerg/Me were chatting on the IRC about this