packages (was Re: [MLton] syntax error for "_address")

[John Reppy]

On Nov 4, 2005, at 7:39 AM, Matthew Fluet wrote:

>
>>>> 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.

I guess the point I'm trying to make about whole-program compilation  
is that the mlton command is this big
monolithic operation that my build script or makefile has to swallow  
whole.  It is not broken up by file or
library, or even by phase (compile vs. linking).  Part of the problem  
is that I'm used to a different model
of building SML programs, so it will take me a while to grok the  
"mlton way."

For C libraries on Unix, I'll need the header file to compile against  
the API and the linker flags.  Transitive
dependencies may affect the linker flags, but not header file.  In  
mlton, I need the mlb file (analogous to
the header), the linker flags, and the names of any supporting object  
files.  What I'd like to see is a more
abstract way of managing that information.

I think that the notions of frameworks and bundles used in MacOS X is  
one of the better solutions to the
packaging problem.  Since frameworks can contain other frameworks,  
you can hide transitive dependencies
if you want.

>
>> BTW, mlton violates this philosophy already; the "-target-*-opt"  
>> flags are
>> redundant with mechanisms already provided by make, etc.
>
> How so?
>

Because I can specialize my MLTON_FLAGS variable to the OS in the  
makefile or configure
script.  For the record, I'm not arguing against these flags, but  
they are inconsistent
with the philosophy of using existing build tools to handle this kind  
of thing.

BTW, the default configuration of mlton, which assumes that it lives  
in /usr is not a good
match for MacOS X.  You should use /usr/local and/or create an  
application bundle.

	- John