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

[Matthew Fluet]

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

Fair enough.  How do you get C libraries into SML/NJ?  I know the CM tools 
mechanism allows you to essentially push the Makefile into the CM file, 
but how to you indicate that you want a .o or a .a file linked in?

As to the monolithicism, I don't see it any different than than what you 
inevitably need to do to get a working executable.  Somewhere, you've got 
to know everything that goes into it and actually link all the pieces 
together.

Maybe the different points of view arise from the relative frequency with 
which one is focusing on the final executable vs. on the intermediate 
object files.  I see mlton as avoiding the middle-man, but if your mental 
model is built around the intermediate object files, I can see the 
disconnect.

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

Again, you need the names of any supporting object files in the C world 
when you want the final executable.  So, I don't see a big difference 
between the two worlds.  Not that they are the best of all possible 
worlds, but rather that they have essentially the same setup, so a 
solution for one ought to work for another.