Re: MLton Homebrew package (Mac OS X)?

On Thu, Dec 31, 2015 at 6:13 PM, Adam Chlipala <[email protected]> wrote:
> (2) The existing binary MLton package hardcodes a path to libgmp that
> apparently is quite nonstandard.  As a result, what I'm told is a
> standard Travis Continuous Integration script based on Homebrew fails to
> run MLton successfully.  See this log:
> https://travis-ci.org/urweb/urweb/jobs/99660971

That looks like a simple packaging bug when I created the statically
linked binary.  (Considering that no one else has ever noted the
problem in 2+ years, it seems that the statically linked binary is not
commonly used.)  You could simply patch the /usr/local/bin/mlton
script to remove the '/opt/local/lib/libgmp.a' option.  As I recall,
the issue on MacOSX is that it isn't feasible to create a completely
statically linked executable (i.e, compiling with '-static') due to
some system libraries not being available and there isn't a way to
indicate that a particular shared library should be linked statically
except by giving an explicit location of the archive.  Thus, when I
built the statically linked binary package, I hacked the mlton script
to statically link to the libgmp.a on my system.  (BTW, /opt/local/ is
the standard location for the MacPorts packaging system, which has
been my preferred packaging system for a few years.)  I was supposed
to restore the original mlton script before tar-ing, but must have
forgotten.

> Is there any hope to invest in getting a fully proper MLton package for
> Homebrew?  Until that point, using MLton is a serious liability for any
> project that itself wants to get into the mainline of Homebrew.

There is always hope. ;-)

The two issues seem to be independent.

I think that you could easily deal with issue #2 (in the short term)
by updating the mlton formula
(https://github.com/Homebrew/homebrew-boneyard/blob/master/mlton.rb)
to include some post-install action that appropriately updates the
/usr/local/bin/mlton script; the diff relative to the MLton 20130705
original script is:

102c102
<         -link-opt '-lm /opt/local/lib/libgmp.a -Wl,-no_pie'      \
---
>         -link-opt '-lm -lgmp'                                    \

You could also deal with the supposed limitation that mlton won't work
outside of /usr/local by some appropriate post-install actions that
replaced the "lib='/usr/loca/lib/mlton'" on line 8 of the mlton script
with the HOMEBREW_PREFIX and also patch in appropriate -I (include
path) and -L (link path) options to find libgmp.

Issue #1 is really a policy issue.  As we've noted elsewhere, we don't
really think that building MLton with SML/NJ is a solution to the
build-from-source issue; see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=220046.  SML/NJ is
essentially a binary package (in the form of the boot files); SML/NJ
has a much more sophisticated rebuild than a simple 'make all', which
I've never seen any 'build-from-source' package system attempt to
replicate.  It seems that if there is enough text flying by during the
"install" process, it is concluded that it must be built from source.
(In SML/NJ's defense, they do a non-trivial amount of rebuild from
source as part of that "install" process and there is a limited form
of internal consistency in as much as the binary boot files must be
loaded into the locally built form source runtime system.)

In any case, perhaps it would suffice to install a temporary copy of
the binary MLton package for the purposes of building the source MLton
package?  As noted above, we can, with some post extract actions,
handle putting the binary MLton package at any suitably obscure,
non-canonical location, as long as it is in PATH for the source MLton
build.

-- 
You received this message because you are subscribed to the Google Groups "MLton-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].


------------------------------------------------------------------------------