[Haskell-cafe] Minimizing cascading rebuilds

Brandon Allbery allbery.b at gmail.com
Thu Mar 29 05:27:22 UTC 2018


The logic has *lots* of additional complications; Haskell isn't C.
https://wiki.haskell.org/Shared_libraries_and_GHC isn't quite about this
(shared libraries have even more complications), but has a reasonable
overview.

Hypothetically, this specific case *could* be handled better. But it
doesn't come up often enough, and the whole thing is tangled enough that
it's only very recently that ghc's dependency handling started to play
along well with nix's idea of how things work, much less anything trickier.

Although this might be one of the rare cases where -split-objs could be
worth the cost (-split-sections is generally preferred with recent ghc, but
wouldn't help with this specific case).

On Thu, Mar 29, 2018 at 1:09 AM, ☂Josh Chia (謝任中) <joshchia at gmail.com>
wrote:

> Hi,
>
> In my project, I have multiple packages. One of the packages, packageA, is
> very fundamental and depended on directly and indirectly by almost all the
> other packages. It has functions that use some hard-coded data (a
> ByteString top-level variable) also defined within packageA.
>
> This hard-coded data is appended regularly, causing packageA to be rebuilt
> and thus almost all the other packages to be rebuilt, and building takes a
> painfully long time. I know I can move this hard-coded data to a file
> that's read at run-time, but that means one more item to plumb in at
> run-time (where to find the file), and IO (preventing the functions from
> being pure), so I would like to keep it hard-coded.
>
> Is there an elegant way to prevent or minimize the cascading rebuild of
> the dependent packages just because the hard-coded data in packageA changed?
>
> For analogy, in C or C++, source code gets compiled to .o files, one for
> each .cpp source file. Multiple .o files get linked into executables. So,
> unless the interface (.hpp files) also change, an implementation (.cpp
> file) change does not cause dependents to be recompiled to get new .o
> files, although dependent executables get relinked. I'm not familiar with
> the compilation and linking logic in GHC so maybe it has additional
> complications.
>
> BTW, I'm using stack, in case it makes any difference to the nature of the
> problem.
>
> Josh
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
>



-- 
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://mail.haskell.org/pipermail/haskell-cafe/attachments/20180329/f71ce2a4/attachment.html>


More information about the Haskell-Cafe mailing list