New `constant` function is hard to use.

[Drup]

I'm not sure what can be done about it, but if I get my pipeline right, here is what must be done if you want to bind an enum and use the type in some function binding:

• Compile an executable calling Cstubs.Types.write_c on a functor implementing Cstubs.Types.BINDINGS.
• Execute said executable to get a C file.
• Compile and execute said C file to obtain an OCaml file.
• Use this ocaml file to implement the functor of type Cstubs.BINDINGS (Not the same!) and call Cstubs.write_c and Cstubs.write_ml.
• Compile and link the generated file to build your binding.
• Hope your buildsystem didn't got a seizure.

Is that right ? Isn't it possible to do a bit simpler than that ? Maybe it's because build systems are not really adapted but this is really awkward and complicated

[whitequark]

Also, this doesn't work for cross-compilation. I need a workflow that doesn't involve executing anything on the host.

[yallop]

I think we can add a workflow that's both simpler and works for cross-compilation. I don't think we even need to change the interface at all, except perahps to add one more function similar to Cstubs_structs.write_c.

The current implementation uses the fact that constant values are available at compile-time to inline them into the generated OCaml code. As @Drup observes, this makes the workflow rather linear: you generate and execute some C code, which generates some ML code, which you finally link into your program. Also, as @whitequark points out, it's not always even possible to execute the generated C code in the right environment. We can address both these concerns with an alternative workflow for Cstubs_structs.TYPE that follows the same pattern as stub generation for functions: generate C and ML directly from the functor containing your bindings, then link the generated C and ML into your program.

[whitequark]

Yup, that was my idea as well.

[Drup]

That sounds much easier to use, yes.