<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Per <a class="moz-txt-link-freetext" href="https://gitlab.haskell.org/ghc/ghc/issues/17191">https://gitlab.haskell.org/ghc/ghc/issues/17191</a> I do hope to
break up our configure script soon.[1] Then the bindist will need
not ship the "entire" configure script, but just what is necessary
to fill in the settings file(s) which have that information Ben
mentions.</p>
<p>I think that will improve the optics of the situation a bit; for
example, I don't think the reduced bindist configure script should
need to worry about directories at all since GHC is relocatable
(when built by Hadrian).</p>
<p>John<br>
</p>
<p>[1]: I will be able to resume work on that once I get to the
bottom of <a class="moz-txt-link-freetext" href="https://gitlab.haskell.org/ghc/ghc/merge_requests/1102">https://gitlab.haskell.org/ghc/ghc/merge_requests/1102</a>.
All help greatly appreciated!<br>
</p>
<div class="moz-cite-prefix">On 8/7/20 11:15 AM, Ben Gamari wrote:<br>
</div>
<blockquote type="cite" cite="mid:87h7teebd3.fsf@smart-cactus.org">
<pre class="moz-quote-pre" wrap="">"Mathieu Boespflug" <a class="moz-txt-link-rfc2396E" href="mailto:m@tweag.io"><m@tweag.io></a> writes:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Hi all,
GHC currently has 3 tier-1 platforms: Linux, macOS and Windows. I'll
focus the dicussion below on these three platforms. The binary
distributions for Linux and macOS are designed to be unpacked, then
the user types ./configure && make install. This is not the case for
Windows.
On all platforms it's possible to create "relocatable" installations,
such that GHC doesn't really care where it's installed, and commands
will still work if the install directory changes location on the
filesystem. So my question is, why do we have a ./configure step on
Linux and macOS? Why could we not have bindists for all platforms that
work like the Windows one? I.e. a binary distribution that you just
unpack, in any directory of your choice, without any configuration or
installation step.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
There are a few reasons:
* Relocatable GHC builds have only been supported for only a few
releases now and only under the Hadrian build system, which is not
currently used to produce our binary distributions (hopefully this
will change for 9.2).
* On Windows we have the luxury of having a very well-controlled
environment as we rely on essentially nothing from the host
system. We provide our own mingw toolchain, statically link
against libc, and have no additional dynamic dependencies.
By contrast, on Linux we have to deal with a much larger
configuration space:
* several linkers, each with their own bugs
* several C compilers, supporting various subsets of functionality
and quirks (e.g. some distributions enable -pie by default, others
do not)
* various LLVM packaging schemes
Since it would be quite expensive to probe the toolchain
characteristics on every compiler invocation, we rather do this once
in the configure script during bindist installation and package the
result in the installed `settings` file.
* On Linux we may have additional dynamic dependencies (e.g. libdw,
numactl) which we check for during configuration time, lest the user
be faced with an unsightly linker error if they happen to be missing
a library.
In principle we could perhaps avoid the need for many of these checks
by creating one binary distribution per operating system distribution.
However, we will first need to move to Hadrian to build our binary
distributions.
Cheers,
- Ben
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
ghc-devs mailing list
<a class="moz-txt-link-abbreviated" href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a>
<a class="moz-txt-link-freetext" href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a>
</pre>
</blockquote>
</body>
</html>