Hi Matthieu, On 06/27/2012 07:18 PM, Matthieu Monrocq wrote: > On Wed, Jun 27, 2012 at 4:15 PM, Axel Naumann <[email protected] > <mailto:[email protected]>> wrote: > Okay. I see three maybe more reasonable options, in decreasing order of > preference for us: > * truncate the cache (we'd anyway only remove the last N files) > * add interface to decide which file should be cached and which > shouldn't, based on the file's full name, in our case we'd likely only > cache read-only files (e.g. STL). > * clear the cache altogether. That's the least performant option for us. > > Should we implement the first option? Or keep the current version? > > Cheers, Axel. > _______________________________________________ > cfe-commits mailing list > [email protected] <mailto:[email protected]> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits > > > There has been a discussion about avoiding warnings in 3rd party headers > on top of STL headers.
Sorry, I don't see yet how that's relevant here. > In this case we could expect that Cling did the > smart things and cached 3rd party headers but not local ones. Or perhaps > had the ability to only clear ones "own" files. Isn't that what I was suggesting as option 2? Are you saying that I missed an existing interface that enables selective caching? > From what I understood, in Cling you don't edit many files at once. > However if we are talking about being able to react to a modification to > a header file, without really knowing its dependencies, then the > truncation cannot be used easily here it seems. We would use truncation as a simplistic dependency analysis: any file that comes after might depend on the file that needs to be removed. The current trunk enables removal of a specific FileEntry. With that we could do more fine-grained analysis, a la include-what-you-use. And that's really our preferred choice. Cheers, Axel. _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
