Re: Is the ORBit2 stubs/skels breakage unacceptable?

[James Henstridge <james daa com au>]

Jeff Waugh wrote:

>Hey,
>
>So, I would like to determine whether the stubs/skels breakage in ORBit2
>0.7.x is acceptable, given that ORBit2 is part of the Developer Platform,
>and ought to have API/ABI compat throughout the 2.x series.
>
>The stubs/skels stuff is a little unclear, because it's not really API or
>ABI breakage, but it does mean that you cannot build software based on 2.0
>and 2.2 on the new ORBit2 without changes to the tarball.
>
>To me, this not only rings warning bells (paranoid or not), but it seems to
>be against the spirit of the API and ABI guarantees -> surely 'third party'
>software [1] should happily build against newer 2.x platforms, as well as
>being technically API/ABI safe?
>
>  (Unfortunately for us, Michael is on holidays right now, so we'll either
>  have to sort this out without him, or wait until he gets back.)
>
>Thanks,
>
>- Jeff
>
>[1] and indeed our own... there are four or so modules in 2.3.x that require
>new releases since the original 2.3.3 tarballs were released due to this
>breakage.
>  
>
 From what I can tell, this is the nature of the stub change:

    * orbit-idl now generates stubs that call a new
      ORBit_c_stub_invoke() API that was added in 2.7.x.  Stubs now
      consist almost entirely of calls to this function, which should
      make forward compatibility easier in the future.
    * Since this is a new API, stubs generated with the new orbit-idl
      will not compile or run with an old ORBit2.  I don't think this is
      too big a deal.  We have never guaranteed complete forward
      compatibility between major releases.
    * Old stubs compiled with old ORBit2 should continue to work after
      upgrading to the new ORBit2 library -- it is backward binary
      compatible.
    * Unfortunately, stubs generated by the old orbit-idl don't compile
      with the new ORBit2 headers (ie. source compatibility of the
      "stubs" API has broken).

This shouldn't really be that big a problem.  While it would be nice if 
old stub sources would compile with the new ORBit2 headers, it shouldn't 
be that big a deal.  Stubs and skeletons are generated files, and 
shouldn't be included in tarballs (the same way you don't include object 
files in tarballs).

If a machine has orbit2 headers installed, then it also has orbit-idl, 
so any arguments about including the generated files for the benefit of 
people without orbit-idl don't really stand up.

If any source tarballs are including generated stubs, then they should 
definitely be fixed.  The fix is to not include the generated files, 
rather than to include newer versions of generated files.

James.

-- 
Email: james@daa.com.au
WWW:   http://www.daa.com.au/~james/