[Haskell-cafe] Minimizing cascading rebuilds

[Gleb Popov]

On Thu, Mar 29, 2018 at 8: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.
>

Since you mentioned C++, why just not use preprocessor? For "developer"
builds you can use a runtime file and for "release" ones - embedded file.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180329/0f896ed4/attachment.html>