[arch-haskell] Enabling profiling (-p) option for AUR packages

Peter Simons simons at cryp.to
Sat Oct 12 07:39:12 UTC 2013


Hi Linus,

if we'd change cabal2arch to set '-p' by default (in addition to
'--enable-shared', which we already set), then all library packages
are going to be compiled *4 times*. Compile times will be twice as
much as they are today. That is a fairly significant change, which
is going to affect all AUR users. So, before making that change, I'd
like to be sure that the consequences are understood.

For me personally, for example, that extra effort is wasted. I've
never profiled a Haskell program, and I don't see myself doing it in
the near future. I just don't need profiling versions of all those
libraries. Even if I would want to profile a Haskell program, I'd
probably build those specific libraries with -p enabled that I
actually need.


 > [Expensive] builds don't really matter that much because Haskell
 > (hackage) packages aren't updated often (at least the ones I use...).

In my experience, many packages on Hackage are updated very often,
and oftentimes those packages are at the bottom of a significant
dependency chain, so these updates trigger fairly extensive
topological re-builds. It's quite common for those builds to take
several hours on my machine. Given that, I don't believe that we can
dismiss build times as a non-issue.


 > I suspect that overwhelming majority of Haskell AUR consumers are
 > Haskell developers, and wouldn't care for the extra build times.

I don't believe that this is a valid assumption. How do you know what the
"overwhelming majority" of AUR users wants?


 > There should be 2 classes of Haskell AUR packages --- libraries
 > vs. user programs, and only enable profiling for the libraries.

Yes, I believe '-p' does that. It's only a short synonym for
'--enable-library-profiling'.

Take care,
Peter





More information about the arch-haskell mailing list