<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 16.7.2024 17.08, Simon Peyton Jones
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAJKmMz8ycJGi0m+S24D7kTiJH8mpmABGBrk0PZ1jEVu9ojrvog@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div class="gmail_default" style="font-family:tahoma,sans-serif">Thanks
Oleg</div>
<div class="gmail_default" style="font-family:tahoma,sans-serif"><br>
</div>
<blockquote class="gmail_default gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Don't write "package (unit)". Write unit.
</blockquote>
<div><br>
</div>
<div style="font-family:tahoma,sans-serif" class="gmail_default">OK.
But: <br>
</div>
<div style="font-family:tahoma,sans-serif" class="gmail_default"><br>
</div>
<div style="font-family:tahoma,sans-serif" class="gmail_default">
> Q: "installed package" means the same as "unit" <br>
</div>
<div style="font-family:tahoma,sans-serif" class="gmail_default">>
Not exactly. <br>
</div>
<div style="font-family:tahoma,sans-serif" class="gmail_default"><br>
</div>
<div style="font-family:tahoma,sans-serif" class="gmail_default">If
a unit is not an installed library, what (precisely) is a
unit?</div>
</div>
</blockquote>
<p>There are "buts". Open units (backpack) are not really libraries.
Executables, test-suites and benchmarks are not libraries, but
still compilation units and cabal-install gives them unit ids; and
probably even tells it to GHC as "-this-unit-id".<br>
</p>
<blockquote type="cite"
cite="mid:CAJKmMz8ycJGi0m+S24D7kTiJH8mpmABGBrk0PZ1jEVu9ojrvog@mail.gmail.com">
<div dir="ltr">
<div style="font-family:tahoma,sans-serif" class="gmail_default"><br>
</div>
<div style="font-family:tahoma,sans-serif" class="gmail_default">Thanks<br>
</div>
<div style="font-family:tahoma,sans-serif" class="gmail_default"><br>
</div>
<div style="font-family:tahoma,sans-serif" class="gmail_default">Simon<br>
</div>
<div style="font-family:tahoma,sans-serif" class="gmail_default"><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Tue, 16 Jul 2024 at 12:36,
Oleg Grenrus <<a href="mailto:oleg.grenrus@iki.fi"
moz-do-not-send="true" class="moz-txt-link-freetext">oleg.grenrus@iki.fi</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>My first comment, which applies across the whole document
is<br>
<br>
Don't write "package (unit)". Write unit.<br>
<br>
Leave the package to be used solely as "A package is the
unit of distribution and versioning.", and use "unit"
consistently for compilation units, and/or "component" (or
more specifically "library" etc).<br>
<br>
The naming of flags is a history artifact.<br>
<br>
The key observation is that "package is the unit of
distribution" is nowadays only a Cabal concept. Only
PackageImports and "imprecise" flags like "-package" (c.f.
"-package-id" which ought to be called "-unit-id") in GHC
really know or care about that. <br>
<br>
Second comment, is that be mindful about `cabal-install`
and Cabal difference. The "3 Cabal" section is really "3
cabal-install", and e.g. stack does things differently.<br>
<br>
> Suppose version 2.3.7 of package P, called P-2.3.7,
depends on package Q.<br>
<br>
Is therefore wrong. You should write "Suppose version
2.3.7 of library P, called "P-2.3.7", depends on library
Q".<br>
<br>
Also libraries can depend on executables: e.g. happy, GHC
doesn't care about those dependencies, but Cabal (the
library, which does the building) does.<br>
<br>
> Each unit has a unit-id, looking like <br>
<br>
*may* look. The unit identifier is a random string
invented by a build tool. It's informative, but it really
doesn't matter much.<br>
<br>
> Q: "installed package" means the same as "unit"<br>
<br>
Not exactly.<br>
<br>
> Q: "package id" means the same as "unit-id"<br>
<br>
I think so. And I'd argue to not use "package id" going
forward.<br>
<br>
> recompiling with no change could change the binary
(non-determinism). Does that change the unit-id?<br>
<br>
It doesn't. Unit-id is invented prior to compilation.
Therefore at least *interface determinism* is important.
Though, cabal-install v2 *never* re-install units to store
database, so determinism is not a hard requirement. <br>
<br>
> A package database can contain many installed
versions of the same package P, or even of a particular
version of P, say P-2.4.3, compiled against different
dependencies.<br>
<br>
Even against the same dependencies, even with the same
flags, if for some reason the build tool changes the way
it computes the unit-id. <br>
<br>
Also s/package/library/. Re-call, there exist non-main
sublibraries.<br>
<br>
> documentation for -package does not clearly specify
how the name of the package is mapped to a unit-id.<br>
<br>
Important bit to remember about "-package" is that it's a
legacy flag, not used by tools anymore. <br>
-package-id looks for the unit exactly. -package scans to
find a matching one, there may be many (and e.g. in case
of the same version, probably non-deterministic choice is
made).<br>
<br>
> This .cabal/store is not a package database.<br>
<br>
.cabal/store/<ghc> **is** an ordinary package
database.<br>
<br>
> Rather, cabal will invoke ghc with a long list of
-package-id <unit-id> flags<br>
<br>
Yes. This is not mutually exclusive. Package database
flags tell where, `-package-id` flags tell what units to
use.<br>
<br>
> Can a package contain multiple public libraries?</p>
<p>Yes. public/private doesn't matter for GHC though. Cabal
enforce the dependency visibility. I.e. private/public is
a Cabal concept. (The visibility is written to interface
files, but it's there solely for Cabal to figure out what
the visibility was. GHC doesn't or at least shouldn't use
that info).<br>
<br>
> Difference between unit-id and ABI hash?<br>
<br>
As far as I remember, unit-id tries to approximate ABI
hash. In fact, there was a request to have GHC output
something like ABI-hash given the set of flags. Currently
Cabal has an ad-hoc implementation to filter out flags
which should not affect the ABI of a package (like
`-fprint-explicit-foralls`. Side note: it would been
clearer if flag name convention would suggest already
whether they affect ABI or not. E.g. `-ddump` flags or
generally `-d` flags don't, but `-f` flags do, except e.g.
`-fprint...` which is kind of `-ddump` like flag). <br>
<br>
</p>
<div>On 16.7.2024 13.20, Simon Peyton Jones wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_default"
style="font-family:tahoma,sans-serif">Friends</div>
<div class="gmail_default"
style="font-family:tahoma,sans-serif"><br>
</div>
<div class="gmail_default"
style="font-family:tahoma,sans-serif">You may remember
a <a
href="https://mail.haskell.org/pipermail/ghc-devs/2024-July/021678.html"
target="_blank" moz-do-not-send="true">recent thread
on ghc-devs about GHC and Cabal</a>. In it I say
how I feel I lack the "big picture" of how GHC and
Cabal interact, and that my mental model is probably
faulty.</div>
<div class="gmail_default"
style="font-family:tahoma,sans-serif"><br>
</div>
<div class="gmail_default"
style="font-family:tahoma,sans-serif">Tom Ellis took
pity on me, and together we wrote <a
href="https://docs.google.com/document/d/1mQEpV3fYz1pHi64KTnlv8gifh9ONQ-jytk5sIHqnV9U/edit?usp=sharing"
target="_blank" moz-do-not-send="true">this
big-picture overview about how GHC and Cabal
interact</a>. Would you like to:</div>
<div class="gmail_default"
style="font-family:tahoma,sans-serif">
<ul>
<li>Read it as a consumer.</li>
<ul>
<li>Does it tell you stuff that is useful?</li>
<li>What else would you like to know?</li>
<li>What is un-clear or missing?</li>
</ul>
<li>Read it as an expert.</li>
<ul>
<li>Is it accurate?</li>
<li>Are any bits misleading?</li>
<li>Do the links go to appropriate places?</li>
<li>What other links or resource would be helpful.</li>
</ul>
</ul>
<div>It is not intended as a replacement for the GHC
user guide, nor the Cabal user guide; rather it is
littered with links to those guides which give much
fuller details. Rather, it is intended to put you
(well, me for one!) in a position where you can more
easily make sense of those documents.</div>
<div><br>
</div>
<div>We'd love to have your help in improving it.</div>
<div><br>
</div>
<div>Simon<br>
</div>
</div>
<div class="gmail_default"
style="font-family:tahoma,sans-serif"><br>
</div>
<div class="gmail_default"
style="font-family:tahoma,sans-serif"><br>
</div>
</div>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
ghc-devs mailing list
<a href="mailto:ghc-devs@haskell.org" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">ghc-devs@haskell.org</a>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a>
</pre>
</blockquote>
</div>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">ghc-devs@haskell.org</a><br>
<a
href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs"
rel="noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote>
</div>
</blockquote>
</body>
</html>