Why bring emacs-module.h in version control ?

[gagbo]

Hello,

Thanks for this project, I wanted to try a first FFI project so I wrote small bindings, and I was wondering how a more fleshed out implementation would look with macros and all so that's nice.

I'm currently wondering why you brought in source the emacs-module.h header ( here ) and only took the 25 version of it. It seems that it prevents users from using Emacs 26+ API.

The "naive" way I used was to use bindgen with a simple wrapper.h that is only

#include <emacs-module.h>

This way the build step automatically fetches and updates bindings for the currently included emacs header, and the compilation of the module will fail if the code uses an API that is absent on their system (emacs_env gets aliased to the most recent emacs_env type). What are the inconvenients of using such a method ?

[ubolonton]

I'm currently wondering why you brought in source the emacs-module.h header ( here ) and only took the 25 version of it. It seems that it prevents users from using Emacs 26+ API.

I aimed for compatibility with older Emacs versions, so this crate targets Emacs 25. When support for additional APIs in Emacs 26+ is added, it will be through feature flags and/or some load/run time checks. When that is added, instead of the header file, the generated Rust code (together with the feature flag checks) will be added to source control, i.e. bindgen usage will be moved from compilation time to write time.

I haven't needed Emacs 26+ APIs, so I haven't added support for them yet.

The "naive" way I used was to use bindgen with a simple wrapper.h that is only

#include <emacs-module.h>

This way the build step automatically fetches and updates bindings for the currently included emacs header, and the compilation of the module will fail if the code uses an API that is absent on their system (emacs_env gets aliased to the most recent emacs_env type). What are the inconvenients of using such a method ?

Depending on the system-provided header file relies on the system package manager (deployment tool) for dependency management (including versioning). Emacs is too niche for most system package managers to maintain this correctly. Furthermore, this is something that is better done by a language-specific package manager (developement tool). (Except for C, because many system package managers are also sort of C package managers.)