There are at least two reasons we are interested in implementing libwayland's ABI:
- It makes sudbury into a drop-in replacement of libwayland.
- If somebody wants to write a compositor with sudbury, then the (e.g.) EGL libraries that they'll want to use expect to be able to call back into libwayland.
Simply taking the relevant C header files and writing appropriate "foreign export" statements seems to work very well. But for correctness and completeness it would be useful to have a tool that constantly monitors the differences of the libwayland and sudbury ABI.
Google turns up "ABI Compliance Checker" and "abidiff" which look relevant, but I did not look into it much.
An added challenge here will be that sudbury's versions of the libraries will expose a lot of extra symbols that come with the Haskell runtime. These should be filtered out of the report.
There are at least two reasons we are interested in implementing libwayland's ABI:
Simply taking the relevant C header files and writing appropriate "foreign export" statements seems to work very well. But for correctness and completeness it would be useful to have a tool that constantly monitors the differences of the libwayland and sudbury ABI.
Google turns up "ABI Compliance Checker" and "abidiff" which look relevant, but I did not look into it much.
An added challenge here will be that sudbury's versions of the libraries will expose a lot of extra symbols that come with the Haskell runtime. These should be filtered out of the report.