llvm dev - Aug 2009 - [LLVMdev] std::cout << *MyModule does not work anymore

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

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