Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
How Rebol borrows code
One of the goals of Rebol is to be able to build a small, complete, standalone interpreter...which does not rely on DLLs or installation. It sticks to a set of somewhat-more-than ANSI C features that strike a balance of being able to compile on quirky-yet-established compilers. All the code is included in the repository: and there are no external library dependencies to configure.
(That is, beyond the Rebol-powered "make-the-makefile" step. This serves as the only necessary "cross-compilation" required, and can be performed on any Rebol platform. Once that's done, all you should need is a not-completely-ancient C compiler.)
Regardless of what other adaptations of Rebol propagate in the wild, the core will seek to ensure that this remains the case. This does introduce some issues, especially in terms of keeping up to date with the latest versions of libraries. While many of the standards Rebol uses are algorithmically stable (JPEG, SHA1, DEFLATE) there are bugfixes and optimizations which will be missed out on as long as the Rebol-bundled-by-hand form of the library subset gets out of sync.
Going forward here are some ideas:
It should be possible (for example) in the build process to use a local library installation. For instance, if you have acquire OpenSSL libs with sudo apt-get install openssl openssl-dev, you should be able to easily choose to build against those instead of the Rebol-bundled OpenSSL subset/snapshot.
There are multiple reasons for wanting to do this. Besides possibly wanting one's own hosted variant to use a fuller version of an API than what the default Rebol host elected to use, there are things like assembly optimizations that are not part of the building philosophy of Rebol and would not be allowed in the bundle.
One of the key factors in making this possible is to ensure that the C API interface definitions used by Rebol are matched (or somehow "impedance-matched" with conditional compilation logic) to the functions in the libraries.
The bundles from libraries pull out only the needed code--modified if necessary, into as few files as possible. But rather than having the bundled monolithic files made by hand and frozen in time, there could be scripts that would take some version(s) of the packages as input and transform them into the desired C file(s).
The script would probably need modification on any major new release of the library. Yet capturing the process would almost certainly make it easier to re-run and tweak when a new version of the library is released, and would help serve as documentation of what exactly the tradeoffs and decisions involved in the subsetting were.