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

Albert Graef wrote:
> I understand that. But in this specific case it would be very easy to
> maintain, no?
FWIW, suggested patch attached. That makes the LLVM 2.5 style
raw_fd_ostream constructor work with the trunk (r80036). Note that this
just adds a second constructor, existing code will continue to work as
before. I'd be happy to prepare an analogous patch for the 2.6 release
branch, just let me know.

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: raw_fd_ostream.patch
Type: text/x-patch
Size: 2863 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20090826/976e987a/attachment.bin>

On Aug 25, 2009, at 3:40 PM, Albert Graef wrote:
> Albert Graef wrote:
>> I understand that. But in this specific case it would be very easy to
>> maintain, no?
>
> FWIW, suggested patch attached. That makes the LLVM 2.5 style
> raw_fd_ostream constructor work with the trunk (r80036). Note that  
> this
> just adds a second constructor, existing code will continue to work as
> before. I'd be happy to prepare an analogous patch for the 2.6 release
> branch, just let me know.
Hi Albert,

Given that we don't guarantee backwards compatibility and prefer to  
keep our APIs clean and tidy, why should we take this?

-Chris

Chris Lattner wrote:
> Given that we don't guarantee backwards compatibility and prefer to
keep
> our APIs clean and tidy, why should we take this?
I already said that: To make it easier for out-of-tree frontends to
support at least the last few LLVM versions. If that's a low priority
then don't. I can live with it.

Please understand that I don't complain about API breakage in general.
It was certainly necessary to implement the multithreading support and
some other stuff in 2.6, and in any case it's a good thing that LLVM
develops new functionality so fast.

In this specific case, however, I think that the API breakage was
completely unneccessary and could have easily been avoided right from
the beginning. In fact, you could have just taken the LLVM 2.5
raw_fd_ostream constructor, turned the 'bool Binary' into an
'unsigned
flags' (with F_Binary=1 for backward compatibility, other flags added as
needed) and old code would have just continued to work and new code
would have been happy, too. But that's not what happened. Instead we now
have a mess of three different raw_fd_ostream interfaces with almost
identical functionality in three consecutive LLVM versions. My patch
just tries to correct this as good as possible given that the API was
already changed in an incompatible way.

Well, that's my take on it. At least I tried. :)

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