[Haskell-beginners] Q 2 of 2: GUI and turnkey compiler?

[Brandon Allbery]

On Fri, May 31, 2013 at 10:20 PM, Gan Uesli Starling <gan at starling.us>wrote:

> So, it would be something to allow an author to issue programs which
> end-users would NOT have to know anything about Haskell itself and would
> have to, at most, perform a two-step, wholly automatic installation
> procedure. Short of this, anything I might aspire to give away free to the
> public en masse, could not conceivably be written in Haskell. In which
> case, I'll respectfully bow out from endeavoring to learn it myself,
> however useful it serves for many another purpose.


Aside from system libraries, if you don't configure your packages to be
dynamic GHC works that way. You can also force system libraries if you use
-static; but note that this also links libc static, which is problematic on
at least Linux and Solaris. (Usually, the only problematic system library
is gmp.)

Note that the gmp case is also not significantly different from any random
Linux program, and you could in fact choose to bundle the appropriate
libgmp.so.whatever with your program and use a wrapper script which sets
LD_LIBRARY_PATH (on Linux or Solaris; DYLD_FALLBACK_LIBRARY_PATH on recent
OS X).

Part of whats throwing you off, I suspect, is that GHC is a native code
compiler. You might want to look at what it takes for applications for
other native compilers, such as C and C++, to bundle necessary libraries.
Perl is an interpreter, and bundling just means including the necessary
modules in a local library and making use of local::lib, or at worst 'use
lib'. It's a much simpler situation than native code compilation. Even in
the case where a .exe is generated for Windows, it's still making use of
interpreted code; Perl cannot be compiled to native code at all sanely. The
.exe instead is instead either a bit like a self-unpacking archive, or a
wrapper which invokes a Perl interpreter on a module tree with various
environment variables and paths set. JForth, similarly, is based on the JVM
instead of native code, and it's trivial to bundle up everything needed in
a jar.

(Apple's done a fair amount of work to make bundling native code easier by
means of special linker paths in application and framework bundles which
both the compile-time ld and the runtime dyld can interpret, but this is of
course not of any use on Windows or Linux.)

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/beginners/attachments/20130531/7111ad13/attachment-0001.htm>