search for: overlayfilesystem

...:get*File through the FileSystem interface, but again that can be handled incrementally 3. at that point we'd have enough stuff in FileSystem to rebase FileManager on top of it; once 1 and 2 are finished for clang/.* we'll be able to completely move the virtual file support over into a nice OverlayFileSystem implementation (argh, I've coded too many of those in my life); 4. add methods to FileSystem to support opening raw_fd_ostreams; this is basically the process for reading mirrored Thoughts? Completely broken approach? Broken order? On a different note, switching to the SourceManager topic - I...

...eSystem interface, but again that can be handled > incrementally > 3. at that point we'd have enough stuff in FileSystem to rebase > FileManager on top of it; once 1 and 2 are finished for clang/.* we'll > be able to completely move the virtual file support over into a nice > OverlayFileSystem implementation (argh, I've coded too many of those > in my life); Is this true (enough support to base FileManager on top)? I'm specifically thinking about some of the places we look at inodes. Or are you expecting to expose some kind of abstracted representation of an inode? > 4. a...

...ut again that can be handled >> incrementally >> 3. at that point we'd have enough stuff in FileSystem to rebase >> FileManager on top of it; once 1 and 2 are finished for clang/.* we'll >> be able to completely move the virtual file support over into a nice >> OverlayFileSystem implementation (argh, I've coded too many of those >> in my life); > > Is this true (enough support to base FileManager on top)? I'm > specifically thinking about some of the places we look at inodes. Or > are you expecting to expose some kind of abstracted representation...

...handled >>> incrementally >>> 3. at that point we'd have enough stuff in FileSystem to rebase >>> FileManager on top of it; once 1 and 2 are finished for clang/.* we'll >>> be able to completely move the virtual file support over into a nice >>> OverlayFileSystem implementation (argh, I've coded too many of those >>> in my life); >> >> Is this true (enough support to base FileManager on top)? I'm >> specifically thinking about some of the places we look at inodes. Or >> are you expecting to expose some kind of abstra...

...eSystem interface, but again that can be handled > incrementally > 3. at that point we'd have enough stuff in FileSystem to rebase > FileManager on top of it; once 1 and 2 are finished for clang/.* we'll > be able to completely move the virtual file support over into a nice > OverlayFileSystem implementation (argh, I've coded too many of those > in my life); > 4. add methods to FileSystem to support opening raw_fd_ostreams; this > is basically the process for reading mirrored > > Thoughts? Completely broken approach? Broken order? > > On a different note, switchi...

...ut again that can be handled >> incrementally >> 3. at that point we'd have enough stuff in FileSystem to rebase >> FileManager on top of it; once 1 and 2 are finished for clang/.* we'll >> be able to completely move the virtual file support over into a nice >> OverlayFileSystem implementation (argh, I've coded too many of those >> in my life); >> 4. add methods to FileSystem to support opening raw_fd_ostreams; this >> is basically the process for reading mirrored >> >> Thoughts? Completely broken approach? Broken order? >> >>...

...handled >>> incrementally >>> 3. at that point we'd have enough stuff in FileSystem to rebase >>> FileManager on top of it; once 1 and 2 are finished for clang/.* we'll >>> be able to completely move the virtual file support over into a nice >>> OverlayFileSystem implementation (argh, I've coded too many of those >>> in my life); >>> 4. add methods to FileSystem to support opening raw_fd_ostreams; this >>> is basically the process for reading mirrored >>> >>> Thoughts? Completely broken approach? Broken order...

...;> incrementally >>>> 3. at that point we'd have enough stuff in FileSystem to rebase >>>> FileManager on top of it; once 1 and 2 are finished for clang/.* we'll >>>> be able to completely move the virtual file support over into a nice >>>> OverlayFileSystem implementation (argh, I've coded too many of those >>>> in my life); >>>> 4. add methods to FileSystem to support opening raw_fd_ostreams; this >>>> is basically the process for reading mirrored >>>> >>>> Thoughts? Completely broken ap...

...; incrementally > >>> 3. at that point we'd have enough stuff in FileSystem to rebase > >>> FileManager on top of it; once 1 and 2 are finished for clang/.* we'll > >>> be able to completely move the virtual file support over into a nice > >>> OverlayFileSystem implementation (argh, I've coded too many of those > >>> in my life); > >>> 4. add methods to FileSystem to support opening raw_fd_ostreams; this > >>> is basically the process for reading mirrored > >>> > >>> Thoughts? Completely brok...

Hi Manuel, On Nov 28, 2011, at 2:49 AM, Manuel Klimek wrote: > Hi, > > while working on tooling on top of clang/llvm we found the file system > abstractions in clang/llvm to be one of the points that could be nicer > to integrate with. I’m writing this mail to propose a strawman and get > some feedback on what you guys think the right way forward is (or > whether we should

Hi, while working on tooling on top of clang/llvm we found the file system abstractions in clang/llvm to be one of the points that could be nicer to integrate with. I’m writing this mail to propose a strawman and get some feedback on what you guys think the right way forward is (or whether we should just leave things as they are). First, the FileManager we have in clang has helped us a lot for