search for: processatoms

...vector of lld::File objects within the InputElement if its a ControlNode 3) The resolver will not process each file but it would process InputElements and would do the following :- 3.1 ) if the InputElement corresponds to a fileNode, the resolver will call in inputElement->processAtoms(*this) and marks the InputElement as already processed. *This would essentially call resolver.processFile(_currentFile)* 3.2) If the inputElement corresponds to a GroupNode, the resolver will call inputElement->processAtom(*this) on *This* *would essentiall call resolver.processGroup(...

...:File objects within the InputElement if its a ControlNode > > 3) The resolver will not process each file but it would process InputElements and would do the following :- > 3.1 ) if the InputElement corresponds to a fileNode, the resolver will call in > inputElement->processAtoms(*this) and marks the InputElement as already processed. > This would essentially call resolver.processFile(_currentFile) > > 3.2) If the inputElement corresponds to a GroupNode, the resolver will call inputElement->processAtom(*this) on > This would ess...

On Sep 4, 2013, at 2:32 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: > On 9/4/2013 4:04 PM, Nick Kledzik wrote: >> I do think we have too many classes. > Agree. >> I thought InputGraph was going to replace InputFiles. > Interesting idea. >> It seems link LinkerInput could be merged into FileNode. > Agree. >> >> Originally InputFiles

Hi Nick, On 9/4/2013 4:04 PM, Nick Kledzik wrote: > I do think we have too many classes. 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