Re: Is the ORBit2 stubs/skels breakage unacceptable?

Jeff Waugh wrote:


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.)


- 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
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
   * 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.


Email: james daa com au

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]