[MLton] Vendor branches (for maintaining ckit, mlnlffi, etc...
ports)
Matthew Fluet
fluet at cs.cornell.edu
Thu Nov 23 12:44:27 PST 2006
> Have you considered using vendor branches, see
> http://svnbook.red-bean.com/nightly/en/svn.advanced.vendorbr.html
> for maintaining the various external library and tool ports to MLton?
It is a possibility, although I haven't thought about it alot. I also
note that SML/NJ has moved to using Subversion for development, so vendor
branches and/or external definitions are possible ways of tracking
changes.
> I was thinking about trying to add support for calling conventions
> specifiers (__stdcall, __cdecl) to ckit and mlnlffigen.
That's a fine extension. But, I'll point out that while ckit is imported
from SML/NJ as a tarball/patch pair, mlnlffigen (and mlnlffi-lib) has
permanently "branched" from the SML/NJ sources. Note that ckit is
essentially pure Standard ML with the patch eliminating the SML/NJ
extensions. On the other hand, mlnlffigen is intimately tied to the FFI
ability of the target compiler, so trying to maintain a small patch is
farily painful.
MLRISC and SML/NJ Library both fall into the tarball/patch category, while
CML falls into the "branched" category; again, the former are simply
patched to remove SML/NJ extensions, while the latter is intimately tied
to the control flow features of the target compiler.
I'm actually in favor of migrating mllex and mlyacc from "branched" to
tarball/patch, since there aren't (many) target compiler dependent aspects
of these programs.
Also, I find the tarball/patch category more transparently "honest" in an
open-source sense. It is a lot easier for those browsing the code to
realize that these directories contain borrowed code. I know the LICENSE
file makes this all pretty clear, but I rarely (if ever) read the LICENSE
files of other projects.
> From my perspective, one nice thing about using vendor branches would be
> that I could develop the extensions "as usual". I wouldn't have to use
> any special patching techniques, take extra copies of the sources or
> remember not to use make clean.
I'm all in favor of making development easier. I've essentially cobbled
together a few scripts for updating the ckit, MLRISC, and SML/NJ Library,
which avoid the problems you note above about losing changes after make
clean.
More information about the MLton
mailing list