I’m tackling the build process for user natives, and trying to figure out how they might actually be used. One key point is that you don’t use the nuanced and complex internal API with them.
From the README I’m writing:
Symbol linkage to the internal libRebol API is automatically provided by the extension. This is the ergonomic external API (e.g. %rebol.h), not the full internal implementation API (e.g. %sys-core.h).
But the initial implementation of user natives DID make the full internal API available. This involved invoking TCC during the build process to pre-process all of the many files included by %sys-core.h into a single blob, and then pack it into the executable. It also made every API and constant available in the symbol table–with its name, to use with tcc_add_symbol().
This predated libRebol’s modern form, so it was the only choice at the time. But now it does not make sense to allow calling %sys-core.h from user natives. If anyone is actually seeking some “optimal efficiency” (with “maximal effort”) that the core API can offer, TCC is not an optimizing compiler in the first place. Any serious larger-scale initiative would want to use the extension model, with a “fancier” compiler and debugger on hand.
libRebol also has a drastically smaller footprint for the header (as %rebol.h is a single standalone file). Not having a large table of every internal API and constant in the system–along with its name–saves space as well. So “rebol.h” is what is used, as the most practical option.
It’s a good change, along with several other good changes in that README that should push the feature along (and reign it in so it’s not holding the build process hostage to a forked version of TCC that I never quite knew how to build).
Because the forum is kind of a “development notebook”, I’m taking some of the code that’s getting the axe and putting it here with some commentary. This makes it easier to link to and talk about, or find later, vs. having it disappear into git archive history without an explanation.