On Thu, Jan 20, 2005 at 02:53:23PM +0900, Jacques Garrigue wrote: > From: Sven Luther <[EMAIL PROTECTED]> > > > Binary compatibility as you get it in C is just a hack: you drop some > > > consistency checks, and hope that the user is clever enough to not use > > > incompatible libraries. Ocaml chooses the safe way. This could be made > > > a bit more resilient, particularly for bytecode, but you would still > > > have breakages in the bug fix branch. > > > > What would be nice in this light, would be an exact list of the digests, and > > thus the modules, that changed, so we could only rebuild the > > packages that are actually affected. That said, such behavior is a > > major drawback for using ocaml in real projects, i believe. > > Not as simple as that. Actually, I tried comparing digests for the > current stable version and 3.08.2, and here are the differences I get. > You can of course do it yourself.
Nice. Stefano tried something such to some degree to analyse the 3.08.2 breakage. > It is not as bad as I would have expected, which explains why you > could believe that binary compatibility is sometimes kept. Exactly, and the fact that maybe i had to big expectations for the bug-fix branches, but well. > (Actually some work was done in the past to avoid having recompiling > everything after any small change in the compiler) Cool. > tet4-lib> find . -name \*.cmi -exec cmp "{}" /usr/local/lib/ocaml/"{}" \; > ./toploop.cmi /usr/local/lib/ocaml/./toploop.cmi differ If i remember right, the toploop is not part of the runtime, and only used by ocamlmktop, right ? No library should depend on it, so there should be no major problem. > ./ocamldoc/odoc_sig.cmi /usr/local/lib/ocaml/./ocamldoc/odoc_sig.cmi differ > ./ocamldoc/odoc_opt.cmi /usr/local/lib/ocaml/./ocamldoc/odoc_opt.cmi differ > ./ocamldoc/odoc_dep.cmi /usr/local/lib/ocaml/./ocamldoc/odoc_dep.cmi differ > ./ocamldoc/odoc_ast.cmi /usr/local/lib/ocaml/./ocamldoc/odoc_ast.cmi differ > ./ocamldoc/odoc.cmi /usr/local/lib/ocaml/./ocamldoc/odoc.cmi differ > ./camlp4/ast2pt.cmi /usr/local/lib/ocaml/./camlp4/ast2pt.cmi differ > ./camlp4/pa_o.cmi /usr/local/lib/ocaml/./camlp4/pa_o.cmi differ > ./camlp4/pa_o_fast.cmi /usr/local/lib/ocaml/./camlp4/pa_o_fast.cmi differ > > tet4-lib> find . -name \*.cmx -exec cmp "{}" /usr/local/lib/ocaml/"{}" \; > ./camlp4/pr_dump.cmx /usr/local/lib/ocaml/./camlp4/pr_dump.cmx differ > ./camlp4/pa_r.cmx /usr/local/lib/ocaml/./camlp4/pa_r.cmx differ > ./camlp4/pa_o.cmx /usr/local/lib/ocaml/./camlp4/pa_o.cmx differ > ./camlp4/pa_o_fast.cmx /usr/local/lib/ocaml/./camlp4/pa_o_fast.cmx differ So ocamldoc and camlp4, the usual culprits. What broke most in 3.08.2 where the thread module. > So, any program that extends ocamldoc or accesses the toploop module > must be recompiled. > Concerning camlp4, I'm not expert enough to know whether a change in > the above interfaces has consequences, but you should assume this is > the case. > As of this writing, the .cmx's don't seem to have changed much. Ok. > Unfortunately, the above is only about changes in the libraries. > There were also bug fixes in the compiler, which result in slightly > different .cmi's for some programs using classes. Ah, but would those not be detected in the above ? Could you elaborate more about those changes ? > For instance, the GObj module in lablgtk. As a result, anything > depending on lablgtk would have to be recompiled, but you cannot > deduce it from the above listing. Yep, but once we know lablgtk needs a rebuild, we can travel the dependency tree from there, no problem. Actually one could imagine a little tool checking all the existing source codes for presence of the affected modules. Reusing some code of ocamldep maybe ? > > > You can safely assume that every new release breaks binary compatibility. > > > (I.e. that some digests in the libraries have changed.) > > > > Yep, understood that now, 3.08.2 came as a big surprise though, as we > > somehow > > expected no binary compatibility change for a bug fix release. > > > > But now we know about it, and i will enable the full-rebuild process for the > > 3.08.3 release, hoping that it will be in time for the debian/sarge release. > > The most reasonable thing to do. Yes, but a huge amount of work in the current state, so if we could avoid it ... > If some individuals want to take the risk of not recompiling what > seems to work, this is ok for them, but usually you don't want to do > this in a distribution. Bah. > If you're ready to do the checks by hand, there is yet another option. > The binary incompatibilities are not platform dependent. So if you > have a problem with the speed of some platforms, you can just > recompile everything on a single platform, and mark everything which > installs modified files as needing a recompilation on all > platforms. Hopefully, this should be sufficient (at least for binary > compatibility). Ah, ok, nice to know. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]