<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 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">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"><u></u>
<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">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">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">ghc-devs@haskell.org</a>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" target="_blank">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">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div>