On Aug 25, 2009, at 1:04 AM, Albert Graef wrote:> . For many applications > other than LLVM itself, the basic LLVM <=2.5 interface which just > overwrites existing files is all that's ever needed.On LLVM trunk, raw_fd_ostream is now back to overwriting files by default, as it is the unanimous preference among in-tree users (and out-of-tree users that I'm aware of). Dan
Dan Gohman wrote:> > On Aug 25, 2009, at 1:04 AM, Albert Graef wrote: >> . For many applications >> other than LLVM itself, the basic LLVM <=2.5 interface which just >> overwrites existing files is all that's ever needed. > > On LLVM trunk, raw_fd_ostream is now back to overwriting files by > default, as it is the unanimous preference among in-tree users (and > out-of-tree users that I'm aware of).But the raw_fd_ostream constructor is *still* incompatible with both LLVM <=2.5 and LLVM 2.6: LLVM 2.5: raw_fd_ostream(const char *Filename, bool Binary, std::string &ErrorInfo); LLVM 2.6: raw_fd_ostream(const char *Filename, bool Binary, bool Force, std::string &ErrorInfo); Trunk (r80020): raw_fd_ostream(const char *Filename, std::string &ErrorInfo, unsigned Flags = 0); It would be helpful to emulate the LLVM 2.5 variant of the constructor on both 2.6 and trunk, so that frontend developers don't have to code against three different versions of the constructor, if they don't need the added functionality. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr.Graef at t-online.de, ag at muwiinfa.geschichte.uni-mainz.de WWW: http://www.musikinformatik.uni-mainz.de/ag
Chris Lattner
2009-Aug-25 21:20 UTC
[LLVMdev] std::cout << *MyModule does not work anymore
On Aug 25, 2009, at 12:24 PM, Albert Graef wrote:> Trunk (r80020): > raw_fd_ostream(const char *Filename, std::string &ErrorInfo, > unsigned Flags = 0); > > It would be helpful to emulate the LLVM 2.5 variant of the constructor > on both 2.6 and trunk, so that frontend developers don't have to code > against three different versions of the constructor, if they don't > need > the added functionality.We do not guarantee API stability at all, so this is just the tip of the iceberg. At one point we discussed having a Version.h that you could #include and then #ifdef based on the version number, I don't know what happened to it if anything. It seems that it would be relatively easy to get autoconf to make a include/llvm/Config/Version.h file that did this. -Chris
Maybe Matching Threads
- [LLVMdev] std::cout << *MyModule does not work anymore
- [LLVMdev] std::cout << *MyModule does not work anymore
- [LLVMdev] std::cout << *MyModule does not work anymore
- [LLVMdev] std::cout << *MyModule does not work anymore
- [LLVMdev] std::cout << *MyModule does not work anymore