Greg Troxel <g...@ir.bbn.com> writes:
> This .so=>devel does not make sense to me. I thought the point was
> that -devel split things that people who wanted to compile against the
> package needed, but not things needed to run.
It seems to me that the dynamic FFI performs, at run time, the same jobs
that a C compiler performs at compile time. If at some point we add
support for accessing preprocessor macros and type definitions (which
seems important), then we'll need the header files as well. So it makes
sense to me that a full-featured dynamic FFI fundamentally depends on
information that's only available in the *-dev packages.
At some point, it might make sense to create a more static FFI that
works more like a C compiler does, splitting the job into compile-time
and run-time phases. This static FFI would be strictly less powerful
than the dynamic FFI, in a similar sense to how syntactic record APIs
are less powerful than procedural ones. However, the static FFI would
be sufficient in most cases, and would have some advantages.
Thoughts?
Mark
