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

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

On Aug 25, 2009, at 11:34 PM, Albert Graef wrote:
> 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.
I don't understand how that can be.  We have made *many dramatic API  
changes* in those releases, surely this isn't the only problem you  
have hit.  Are you using the C++ APIs?  We try to keep the C apis as  
stable as possible, is it possible to use those?

Just to be clear, I'm not trying to be a butthead about this :).  I  
just see that API stability in almost a binary way: you either try to  
keep it or not.  If not, I don't think that trying to paper over small  
changes like this is worth it.
>  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
Sure, but again, the change wasn't made for an arbitrary reason:  
moving them to the end allows them to be optional, so that they do not  
need to be specified.  This makes the API more elegant.  I'm not  
willing to sacrifice small bits of API elegance unless we actually get  
something useful out of this.  Given the other massive and widespread  
api changes in 2.6, I can't fathom how this can actually matter.

-Chris

On Wed, Aug 26, 2009 at 1:20 PM, Chris Lattner<clattner at apple.com>
wrote:
>
> On Aug 25, 2009, at 11:34 PM, Albert Graef wrote:
>
>> 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.
>
> I don't understand how that can be.  We have made *many dramatic API
> changes* in those releases, surely this isn't the only problem you
> have hit.  Are you using the C++ APIs?  We try to keep the C apis as
> stable as possible, is it possible to use those?
>
> Just to be clear, I'm not trying to be a butthead about this :).  I
> just see that API stability in almost a binary way: you either try to
> keep it or not.  If not, I don't think that trying to paper over small
> changes like this is worth it.
Mmm... I agree in general, but I think it's worth considering that
this change could silently hit someone updating from an older version
of LLVM.

-Eli

Chris Lattner wrote:
> I don't understand how that can be.  We have made *many dramatic API
> changes* in those releases, surely this isn't the only problem you have
> hit.
Surely not. :)
> Are you using the C++ APIs?
Yes.
> We try to keep the C apis as stable as possible, is it possible to use
those?
No, but that's good to know. I might want to generate a Pure-LLVM
binding via the C API some time.
> Just to be clear, I'm not trying to be a butthead about this :).  I
just
> see that API stability in almost a binary way: you either try to keep it
> or not.  If not, I don't think that trying to paper over small changes
> like this is worth it.
You said it. :) Case closed. I've solved this already in my configury
anyway.
> Sure, but again, the change wasn't made for an arbitrary reason: moving
> them to the end allows them to be optional, so that they do not need to
> be specified.  This makes the API more elegant.
I understand that.

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