Henry is correct that the MLton compiler (the runtime, basis library implementation, and compiler proper) do not depend on ckit (or any of the (re)distributed SML/NJ libraries), the benchmarks, or on mlnlffigen, nor are those components required for using MLton (unless, of course, the program being compiled explicitly references them). If Debian wants to carve up the packages for MLton in a different way, then that seems fine, but I'm not inclined to do serious rearrangements of the GitHub repository or of the source releases that we (upstream) package. I appreciate the licensing issue, but consider it fairly low stakes for decades old code.
Florian is correct that MLton has packaged mlnlffigen both out of convenience (as we have packaged mllex and mlyacc) for users and because MLton requires the tool to generate slightly different code. On Mon, Nov 1, 2021 at 3:55 PM Henry Cejtin <[email protected]> wrote: > Your right, but I think (not on the basis of real knowledge) that > ml-nlffigen isn't used in either the compilation > of the MLton compiler, nor by the MLton compiler in compiling user > code. I thought that it was > for a MLton compiler user to use, and had been tweaked so that the > output was usable by MLton. > > I certainly could be wrong about this. >
