[bitc-dev] Retrospective: separate compilation and dynamic linking needs programmer knowledge?
Jonathan S. Shapiro
shap at eros-os.org
Mon Apr 9 13:41:34 PDT 2012
On Mon, Apr 9, 2012 at 10:53 AM, Geoffrey Irving <irving at naml.us> wrote:
> It seems like the discussion so far on separate compilation has been
> trying for some solution that's better in principle than the C/C++
> module of header files.
I guess that I see it the other way around: having started down the type
class route, we found (in hindsight) that we needed to have gone down a
more exposed path.
Given a choice, I tend to prefer something like the CLI approach to the
header file approach. It's more in keeping with a range of continuous
compilation strategies. But the distinction is mainly about what level of
abstraction the code appears at.
If we take dynamic linking and library
> versioning into account...
Once again, library versioning is completely orthogonal. That's a library *
naming* problem at the link level, pure and simple. Dynamic linking *per se* is
not the problem either, except that in the presence of delayed type binding
and consequently delayed method resolution it introduces a requirement for
link-time code generation.
> Say we have a library B depending on another library A. If we're
> trying to replace the current ecosystem of dynamic libraries, we would
> like to be able to change and recompile A without touching B at all.
We aren't trying to change that part of the ecosystem. Partly because I was
on the [extended] team that specified and implemented ELF dynamic libraries
in UNIX, specified their implementation for MIPS, and built *both* of the
first two debuggers that handled them correctly. Definitely a problem that
I'm not eager to look at again.
> This only works if the parts of A that were likely to have changed
> were somehow marked as off limits to the optimizer when B was built.
Actually, that's not true. There are a whole range of other design options
that can be considered here.
> Moreover, the structure of A should be such that B can be compiled by
> looking at only a portion of the files of A.
That's a nice goal, but it's not how things work in parametric languages.
The way to think about this is as follows:
- In C++, 10% of the source lines of code are template (i.e. parametric)
- In BitC, 95% of the source lines of code are parametric.
Given the 95% level, a distinction between headers and source for purposes
of code generation ceases to make much sense. We still need something that
defines interface contracts between libraries, and that has some of the
feel of a header file, but it exists for a different reason.
> The conclusion seems to be that you either need header files, or you
> need to abandon the notion that upstream libraries can be recompiled
> without recompiling downstream code. Is this a correct
> characterization of the situation?
There are quite a number of other options, so no, I don't think that's a
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the bitc-dev