On Tue, Apr 05, 2011 at 01:25:34PM +0200, Peter Simons wrote:
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.
So I take it that some Haskellers don't profile at all, and some (like me and Peter Hercek) do.
[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.
So some people's favorite AUR packages are updated often, and some are not.
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?
It was a suspicion. I just assumed that 95% of AUR users are developers, since sooo many packages from hackage are libraries, not standalone programs. But it could certainly be the case that most AUR users just use one or two haskell programs that themselves depend on other libraries, in which case profiling is totally unnecessary.
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'.
I've given some thought to this again, and I think I have a better idea --- instead of (1) enabling profiling by default, or (2) manually adding '-p' to all library packages, how about instead make cabal2arch generate an if/else statement inside the PKGBUILD somewhere, looking for a "PKGBUILD_HASKELL_ENABLE_PROFILING" environment variable? If it is defined, then the PKGBUILD would add the the '-p' option, and if not, then no changes would be made. Then anyone who wants profiling can just define that variable somewhere (~/.zshrc, ~/.bashrc, etc.) as a one-liner addition and be done with it. To me this seems to be the only sensible solution, considering the diversity of the AUR users' needs. Does anyone have a better suggestion? It should be a trivial change (I haven't looked at the cabal2arch source yet but the idea is so simple...). I'll take Magnus's suggestion and do the github/pull request thing soonish once this discussion settles down. -Linus