Bindings with C library

[cyrusmsk]

I'm trying to build an example with C API for different than C/R/Python language.

Several questisons:

1. What is the suggested way of storing/building original library? Should it be located withing the binding library? Or we can just assume that the library is installed in the system?
2. I'm using macOS arm. Currenttly I'm installed nanoarrow with "brew install". I've checked the installed .a and .dylib files with the command:
   nm -gU
   They don't have methods ArrowArrayAppendInt/ArrowArrayAppendUInt. Though these methods are mentioned in the C API documentation.
3. The library currently installing in the strange format. For example, it is putting nanoarrow.h to 2 folders: /opt/homebrew/include/nanoarrow and /opt/homebrew/Cellar/nanoarraiw/0.8.0/include. The first one has include in the form "#includ "nanoarrow/common/inline_types.h" - but there is not nanoarrow folder for this header.
   Not sure if you are officially maintaining brew formula, but some clarification on the proper read for headers would be useful. For different OSes.

Because I want to build the library that could be used by other users with different configurations and OSes.

[paleolimbot]

Today I learned we have a Homebrew formula!

What is the suggested way of storing/building original library?

Most users of nanoarrow create a single-file include (nanoarrow.c/nanoarrow.h) as described in the README. A real live example of mine is here ( https://github.com/geoarrow/geoarrow-r/blob/main/vendor-nanoarrow.sh ). Recently we do have reasonable package manager support (Homebrew, vcpkg, conan, wrapdb/meson) but we don't have a Linux package and likely won't for some time.

Note that it's usually a good idea to use a namespace (i.e., -DNANOARROW_NAMESPACE=MyPkgName) if you are building a library that may coexist in the same process with another shared library (e.g., a Python or R package).

I've checked the installed .a and .dylib files with the command

I believe ArrowArrayAppendInt/ArrowArrayAppendUInt are static inline, which mean they are defined in the header files and not as symbols in the shared library.

For example, it is putting nanoarrow.h to 2 folders

I believe these are symlinks and I think this is common for Homebrew. It is intended to be built with -I/opt/homebrew/include (or similar), which is how the headers find each other.

Because I want to build the library that could be used by other users with different configurations and OSes.

Probably you want to just vendor nanoarrow into your project 🙂

[cyrusmsk]

Vendoring the library seems fine.
Though static inline methods are adding complexity for automatic bindings generation

[cyrusmsk]

Am I right that IPC and Device extensions are not part of the standard "nanoarrow.c/nanoarrow.h" ?

[paleolimbot]

Yes, those can be bundled and/or built as well (e.g., nanoarrow_ipc.c/h and nanoarrow_device.c/h) but aren't included in nanoarrow.c/h.