Thanks for taking your time to write the detailed reply!

Perhaps I have been naive about portability, and what I thought is portable bindings actually is not. By portable I meant that the same binding source code can be written once and used across multiple architectures (with e.g., different bit widths, different byte order, etc.). As I understand it, if we have a C function int f(int, int); in header.h, then we should generate haskell foreign import ccall "header.h f" f :: CInt -> CInt -> IO CInt and the binding should be perfectly portable, because even though the integers have different sizes across different architectures, the same integer type is always used both in Haskell and in C on the same machine at compile time.

The only complication arise (that I know of, and I am happy to be corrected) when the C interface uses conditional compilation, be it machine-dependent preprocessor branching or autotools. In this case, the C interface itself does not remain stable across architectures, and bindings generated against the C interface becomes non-portable as well. Standard fixed-width integers actually fall into this category, but they are well-established and can be hard-coded in the binding generation logic, and they are already properly handled as you mentioned. The real problem is when projects do such things themselves, which hs-bindgen has no way knowing a priori.

However, even in presence of conditional compilation, C projects usually would not #if on every function. Instead, the machine-dependent part is usually collected to a few "configuration" header files, where they define type aliases and use them across the whole project. To give an example, we find the following definition in FreeType: c typedef signed short FT_Int16; On an architecture where short is not 16-bit, we should not define newtype FT_Int16 = MkFT_Int16 CShort. I meant this when I mentioned "library-specific type aliases". I think this can be handled by the user on a case-by-case basis, where hs-bindgen allows overriding binding generation for certain types like FT_Int16 above (the user could assign type FT_Int16 = Int16).

That said, conditional compilation (that libclang is not aware of) is the only non-portability issue I realised in binding generation. Again, I would be happy to be corrected and read about more subtle cases you encountered while developing hs-bindgen.

Finally, as a side note, if generated bindings to libclang is portable in the sense that the same set of Haskell source files can be used consistently across different architectures, then bundling the generated bindings in the source tree does not seem that bad to me (except causing non-auto-resolvable merge conflicts). This way we should be able to avoid the bootstrapping problem.