On Wed, Jan 09, 2008 at 09:58:12AM +0100, Stefano Zacchiroli wrote: > Let's see what would be my top wish-list items: > 1) ability to add .mli components without breaking the ABI > 2) ability to change non semantic relevant .mli parts (e.g. comments) > without breaking the ABI > 3) (optional, i.e. which can be enabled/disabled) safety to change the > implementation without breaking the ABI (ATM md5sums at the .mli > level do *not* guarantee that native code linking would work, due to > inlining) > > Richard, and d-o-m folks, any other request which come to your mind? > > (1) and (2) above would presumably require to keep not only a single > md5sum per .cmi, but rather an associative list mapping .mli component > identifiers to md5sums of their "types". Then, checking for "consistent > assumption" on such a structure would be far more expensive, but at > least it would be required only at link time. > > (3) can be enforced at package maintenance level by disabling inlining > for native code object, and I say it would be a reasonable thing to do > in distributions. Haven't the C lib stuff already experienced such > issues? (or maybe not, I don't know if code inlining across libraries > is possible in C/C++) if so maybe we can learn from them?
This is all great stuff. My only wonder is if it's possible & how simple or otherwise the implementation will be ... I have little experience in hacking the compiler. Rich. -- Richard Jones Red Hat -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
