packages (was Re: [MLton] syntax error for "_address")
Matthew Fluet
fluet@cs.cornell.edu
Fri, 4 Nov 2005 08:39:58 -0500 (EST)
>>> I think that this is a fine philosophy (in fact, it is the one that I
>>> follow for Moby), but the fact that mlton is a whole program compiler
>>> means that I have no way to use the underlying system tools to package
>>> SML libraries.
>>
>> I don't understand what the problem is. There is the (obvious) fact
>> that MLton needs the whole (SML) program in order to compile, but do
>> you mean something else? Why doesn't packaging SML libraries as
>> source work?
>
> Because there isn't a single logical entity that represented the library.
> At best, I'll need an mlb file and an include file for the application's
> makefile. Of course, if we get into a sharing situation, the include
> file approach will break.
I'm trying to understand John's point of view. Are you equally critical
of the situation in mono-lingual but multi-library software composition?
For example, in a straight C project which makes use of other C libaries,
I still need to do two things: 1) use #include "gmp.h" in the appropriate
source files, and 2) use -L... -lgmp in the appropriate linker invocation
(and, possibly, 3) use -I... in the appropriate compiler invocations).
I guess MacOS's -framework flag avoids the tedium of -I... -L... -l...,
but you're still responsible for knowing what libraries contribute to your
software when you build it. Note, this remains the case through all the
transitive dependencies.
> BTW, mlton violates this philosophy already; the "-target-*-opt" flags are
> redundant with mechanisms already provided by make, etc.
How so?