search for: foreachinitalatom

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 directly. 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, > >...

...e 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 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, 2...

...Agree. > I thought InputGraph was going to replace InputFiles. Interesting idea. > It seems link LinkerInput could be merged into FileNode. Agree. > > 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. Yes, this would be nice. I will try to write a proposal in the next few days. > What should the interface be that the Resolver uses for handling groups? bool resolveUndefines(std::vector&...

...ht InputGraph was going to replace InputFiles. > Interesting idea. >> It seems link LinkerInput could be merged into FileNode. > Agree. >> >> 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. > Yes, this would be nice. I will try to write a proposal in the next few days. >> What should the interface be that the Resolver uses for handling groups? > bool resolveUndefines...

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

...tGraph was going to replace InputFiles. >> Interesting idea. >>> It seems link LinkerInput could be merged into FileNode. >> Agree. >>> 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. >> Yes, this would be nice. I will try to write a proposal in the next few days. >>> What should the interface be that the Resolver uses for handling groups? >> bool reso...

...g to replace InputFiles. >>> Interesting idea. >>>> It seems link LinkerInput could be merged into FileNode. >>> Agree. >>>> 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. >>> Yes, this would be nice. I will try to write a proposal in the next few days. >>>> What should the interface be that the Resolver uses for handling groups? >>&g...