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

[John Reppy]

On Nov 2, 2005, at 5:27 PM, Stephen Weeks wrote:

>
>> I have a library of SML code that I want to use in multiple
>> applications.  It depends on C libraries and it uses "_export" to
>> generate C code.  I can provide both a Makefile and mlb file for the
>> library, but how will these connect to the application build
>> process?  How am I going to pass requirements for C libraries,
>> etc. up to the application's build process?
>
> How would you do this if your library was written in C instead of SML?
> (I do not mean this sarcastically)

One the Mac, I just say "-framework library" and I get both the  
include-file
and link-time hooks I need.  Even in other systems, I can build a single
file that packages the code for my library and that can be shared by
multiple clients.

>
> Our philosophy is to integrate with existing tools and build processes
> as much as possible.  Producing our own replacement for make or
> existing packaging systems would take a lot of effort, would likely
> produce worse results (than the better ones anyway), and would make
> tools harder for people to use than the ones they know.  So, Matthew's
> answer to your question is the right one: MLBs live within whatever
> existing mechanism (e.g. make) you have for expressing requirements,
> handling platform dependencies, and building applications.
>
> MLBs exist to solve a problem that makes sense solely in the context
> of SML (namely, namespace control at the module level) and solve the
> problem in the spirit of SML, with a clean static and dynamic
> semantics.  Other components necessarily sit on top of MLBs to make
> real-world things happen, but to complicate MLBs to handle such issues
> would lead to a worse overall system with fewer clearly understood
> components.

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 know what the right solution is, but I think
that there needs to be a mechanism for packaging both SML and C
code together in a library.  Anyway, I asked the question because I'm
trying to build some graphics libraries that I plan to use in a bunch
of applications and I wanted to know what the "best practice" was.
It sounds like this is still an open problem.

BTW, what does MLB do about the diamond problem?  E.g., if I have a
library A that B and C depend on, and then I write an application
that uses both B and C, do I get two copies of A or does it share?

>> The GHC package system provides a nice mechanism for this problem;
>> you might want to check it out.
>
> I am passingly familiar with Haskell's CABAL and am not at all
> convinced that its package description files are a good solution to
> the problem.

I think that CABAL is a tool that is supposed to support a common  
package
build specification across multiple compiler/OS combinations.  What I  
think
is attractive about the Haskell system is that they recognize that it is
not good enough to just think about libraries composed of Haskell code.
Instead, they are tackling the important situation of libraries  
comprised
of both Haskell and C code.  Once you have a decent FFI mechanism, this
is the logical next step.

	- John