[MLton] Support for link options in ML Basis files

[Anoq of the Sun]

Hello!


I have just breifly skimmed the mail below.
I have some old SDL bindings here:
http://www.hardcoreprocessing.com/pro/sdlml/index.html

It's way outdated and I have some better and more
complete bindings in my repository. As usual I'm just
not sure when I find the time to finish the last
details and release it :-)

Right now I have an exam on wednesday... "Types
and Programming Languages"...
(hopefully my last computer science course
before I can start working on ML-related
projects at uni. :-)

I was wondering about one thing: How did you
solve the issue of the main function with SDL?
To get my bindings to work with MLton I had
to include SDL.h in MLtons runtime file where
the main function resides, so that SDL.h mangles
the main function to SDL_main.


Cheers
-- 

Chris Clearwater wrote:

 > Matthew Fluet wrote:
 >
 >>> Are there any plans to support link options in ML Basis files? For
 >>> example, I have written bindings to some SDL functions neccesary to use
 >>> in place of GLUT with OpenGL.  It would be nice for applications which
 >>> used the SDL and OpenGL bindings to simply add "sdl/sdl-lib.mlb" and
 >>> "gl/gl-lib.mlb" to their .mlb files and have MLton automaticaly use the
 >>> supplied link options when compiling the final executable.
 >>>
 >>
 >>
 >>
 >> See
 >>  http://mlton.org/pipermail/mlton/2004-July/025553.html
 >> for a similar proposal and
 >>  http://mlton.org/pipermail/mlton/2004-July/025554.html
 >> for a reply.
 >>
 >> I believe that the reply still applies.
 >>
 >>
 >>
 >>> Also, is
 >>> their a way to have MLton tell you where it keeps SML libraries (for
 >>> example, /usr/lib/mlton/sml/ on my Debian machine) so you could have a
 >>> makefile target install the library in the appropriate place?
 >>>
 >>
 >>
 >>
 >> I don't think we have a simple way of doing it, but there are a couple of
 >> hacks that would get you that functionality.  If you give mlton a
 >> nonexistent .mlb file, it will print out the path with all MLB path
 >> variables expanded:
 >>
 >> -bash-2.05b$ mlton '$(SML_LIB)/z.mlb'
 >> Error: <string> 1.1.
 >>  File /usr/lib/mlton/sml/z.mlb does not exist.
 >> compilation aborted: parseAndElaborate reported errors
 >>
 >> Alternatively, compiling a .mlb file with -stop f will yield a list of
 >> files (suitable for a Makefile dependency), again with all path variables
 >> expanded:
 >>
 >> -bash-2.05b$ mlton -stop f '$(SML_LIB)/basis/basis.mlb'
 >> /usr/lib/mlton/sml/basis/misc/primitive.sml
 >> /usr/lib/mlton/sml/basis/posix/primitive.sml
 >> ...
 >> /usr/lib/mlton/sml/basis/libs/basis-2002/top-level/overloads.sml
 >>
 >>
 >> From either of these, a little grep and sed hackery could should yield the
 >> path you are looking for.
 >>
 >> _______________________________________________
 >> MLton mailing list
 >> MLton@mlton.org
 >> http://mlton.org/mailman/listinfo/mlton
 >>
 >>
 >>
 > I wonder then how you guys would feel about using Pkgconfig (http://www.freedesktop.org/Software/pkgconfig).  Pkgconfig in combination with mlbs would provide you a fully functional packaging 
system with minimal effort.  For example, with my SDL bindings I would just install a file such as "mlton-sdl.pc" in /usr/lib/pkgconfig/. An example of what this might look like:
 >
 > Name: MLSDL
 > Description: SDL bindings for the MLton compiler
 > Version: 0.1
 > Libs: -L/usr/lib/mlton/sml/sdl -lSDL -lpthread
 >
 > Now any program wishing to use the SDL bindings would simply compile with "-link-opt `pkg-config --libs mlton-sdl`" and include $(SML_LIB)/sdl/sdl.mlb in their mlb.  This nicely seperates the clean 
SML world from the messy C world. As an advantage, any package requiring another package, such as the case of mlgtk requiring gtk+-2.0, it would simply need to add a "Requires" line and it would draw 
compile options from the target package. This would also serve for MLton packages depending on other MLton packages. Requires lines can also deal with version dependancies. Pkgconfig also supports 
arbitrary variables in the ".pc" file.  There are some commonly defined variables such as "prefix", "libdir" and "includedir". MLton could define a variable such as "smllib" for packages to query 
where to install their files.
 >
 > Although it is by no means required, pkgconfig integrates very well with autoconf/automake. Even if you don't wish to use these tools for MLton, distributers of individual MLton packages could use 
them if they prefer the automation they provide. For more information, check out "man pkgconfig".
 >
 > The obvious downside to this is that it adds a build dependancy on Pkgconfig. This isn't so bad as it only affects people compiling themselves, in which case they may already have pkgconfig 
anyways. My machine has 46 packages already installed in /usr/lib/pkgconfig. Admitidely, most of these are gnome/gtk related, but a fair number are not and Pkgconfig is gaining in popularity all the time.
 >
 > This information comes from my breif investigation, maybe there is someone else more familiar with pkgconfig that can comment?
 >
 > _______________________________________________
 > MLton mailing list
 > MLton@mlton.org
 > http://mlton.org/mailman/listinfo/mlton
 >
 > .
 >