[Haskell-cafe] Minimizing cascading rebuilds

[Vo Minh Thu]

Hi,

Maybe that switching to another linker can help, e.g. gold or the llvm one.

Cheers,
Thu

Le 29 mars 2018 07:43, "Theodore Lief Gannon" <tanuki at gmail.com> a écrit :

> (sorry for duplicate, failed to reply to list)
>
> Haskell is going to be unwieldy if you try to code in a non-functional
> style! Your data, however static, should be passed as an argument to
> functions that need it. In this case, "as an argument" should probably be
> read as "with the Reader monad."
>
> If you want to avoid loading via IO, you can still put your data set in a
> separate package. It will depend on packageA to define the data type, but
> nothing but your final executable has to depend on it -- in fact, it can
> probably live in the executable's source tree. Put all of your logic that
> depends on that data (directly or indirectly) in a Reader, and invoke it at
> the top level.
>
> Once you've got that down, it's very much worth reading up on transformers
> and mtl. I'd also suggest looking at the Rio[1] prelude (currently not
> quite to a stable release, but will be inside the month) which is built
> around encouraging current best practices. Once you know the tools, this
> style becomes convenient, extremely versatile, and helps avoid unnecessary
> dependencies all over the place.
>
> [1] https://github.com/commercialhaskell/rio
>
> On Wed, Mar 28, 2018, 10:11 PM ☂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.
>
>
> _______________________________________________
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180329/59405823/attachment.html>