AUR Comment for haskell-cmdargs
from http://aur.archlinux.org/packages.php?ID=30061 peti wrote: Hi Listdata, we haven't enabled profiling builds, because no-one ever asked for it. The Haskell packages that are distributed in [extra] are built with '-p' by default, but none of the AUR packages are. The reason for that is that [extra] packages are downloaded in binary form, so build times don't matter much for the average user. Packages from AUR, however, need to be compiled on the user's machine. These builds are fairly expensive already, because every library needs to be compiled twice to generate static and shared variants. If we'd add '-p' to those builds, too, then compile times would go up even further. That seems like a fairly high cost to impose on everyone in order to get a feature that most people don't need. --- If you no longer wish to receive notifications about this package, please go the the above package page and click the UnNotify button.
Hello, I am listdata and I wanted to bring this discussion (re: enabling profiling builds for AUR packages): http://aur.archlinux.org/packages.php?ID=30061 onto the mailing list. Here are my 2 cents: @peti: From an end-user perspective (well, my biased perspective), the expensive builds don't really matter that much because Haskell (hackage) packages aren't updated often (at least the ones I use...). And from a Haskell developer's perspective, a great number of Haskell packages are _libraries_ (such as cmdargs, haskell-pretty-show, haskell-haskell-lexer, haskell-regex-pcre) where enabling profiling makes a lot of sense. I personally love profiling my Haskell programs, and it bugs me that the AUR set of packages don't have it enabled by default (based on cabal2arch's current defaults --- thanks magus for pointing this out). Does anyone else find it annoying that you can't profile your Haskell program because 1 or 2 AUR package doesn't have profiling enabled? I suspect that overwhelming majority of Haskell AUR consumers are Haskell developers, and wouldn't care for the extra build times. Then again, maybe there should be 2 classes of Haskell AUR packages --- libraries vs. user programs, and only enable profiling for the libraries. This setup would make much more sense, but at the cost of manually identifying certain packages as libraries (from the thousands currently out there.) If there are any Arch Haskell developers reading this, please chime in. On Thu, Mar 31, 2011 at 05:26:28AM -0400, AUR Feedback wrote:
from http://aur.archlinux.org/packages.php?ID=30061 peti wrote:
Hi Listdata, we haven't enabled profiling builds, because no-one ever asked for it. The Haskell packages that are distributed in [extra] are built with '-p' by default, but none of the AUR packages are. The reason for that is that [extra] packages are downloaded in binary form, so build times don't matter much for the average user. Packages from AUR, however, need to be compiled on the user's machine. These builds are fairly expensive already, because every library needs to be compiled twice to generate static and shared variants. If we'd add '-p' to those builds, too, then compile times would go up even further. That seems like a fairly high cost to impose on everyone in order to get a feature that most people don't need.
--- If you no longer wish to receive notifications about this package, please go the the above package page and click the UnNotify button.
_______________________________________________ arch-haskell mailing list arch-haskell@haskell.org http://www.haskell.org/mailman/listinfo/arch-haskell
On Fri, Apr 01, 2011 at 09:48:35PM +0200, Peter Hercek wrote:
On 04/01/2011 08:45 PM, Linus Arver wrote:
If there are any Arch Haskell developers reading this, please chime in.
I would prefer profiling to be on by default for aur. I do not care if it builds longer.
Peter.
_______________________________________________ arch-haskell mailing list arch-haskell@haskell.org http://www.haskell.org/mailman/listinfo/arch-haskell
That makes it 2 votes to 0. So, is cabal2arch going to add the profiling build by default? -Linus
On Mon, Apr 04, 2011 at 05:03:13PM -0700, Linus Arver wrote:
On Fri, Apr 01, 2011 at 09:48:35PM +0200, Peter Hercek wrote:
On 04/01/2011 08:45 PM, Linus Arver wrote:
If there are any Arch Haskell developers reading this, please chime in.
I would prefer profiling to be on by default for aur. I do not care if it builds longer.
That makes it 2 votes to 0. So, is cabal2arch going to add the profiling build by default?
It's a trivial to make that change, if you want it, create a clone on github, make the modification, and file a pull request. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus Perl is another example of filling a tiny, short-term need, and then being a real problem in the longer term. -- Alan Kay
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
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
Hi Peter, So it's been about a week now, and the discussion has more or less settled. I've sent a pull request on github detailing everything. For those on the ML, it is: https://github.com/archhaskell/archlinux/pulls It turns out that the archlinux repo (and not cabal2arch) is the one responsible for the default PKGBUILD text that we were discussing. I will update the Arch Wiki as necessary once the changes are pulled. -Linus
Hello all, The wiki page has been updated to reflect the use of the new PKGBUILD_HASKELL_ENABLE_PROFILING environment variable: https://wiki.archlinux.org/index.php/Haskell_package_guidelines So define that variable if you want to enable profiling builds for all of your Haskell AUR packages (as they are updated with the newer cabal2arch version 1.1+). -Linus
On Sat, May 14, 2011 at 07:55:24AM -0700, Linus Arver wrote:
Hello all,
The wiki page has been updated to reflect the use of the new PKGBUILD_HASKELL_ENABLE_PROFILING environment variable:
https://wiki.archlinux.org/index.php/Haskell_package_guidelines
So define that variable if you want to enable profiling builds for all of your Haskell AUR packages (as they are updated with the newer cabal2arch version 1.1+).
Excellent, but what is the practice for [haskell], is profiling turned on for the binary packages? /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus I invented the term Object-Oriented, and I can tell you I did not have C++ in mind. -- Alan Kay
On Sat, May 14, 2011 at 10:49:14PM +0100, Magnus Therning wrote:
Excellent, but what is the practice for [haskell], is profiling turned on for the binary packages?
Yes. Quoting peti's comment (Thu, 31 Mar 2011 09:26:28 +0000) on haskell-cmdargs: "...The Haskell packages that are distributed in [extra] are built with '-p' by default, but none of the AUR packages are. The reason for that is that [extra] packages are downloaded in binary form, so build times don't matter much for the average user." See http://aur.archlinux.org/packages.php?ID=30061 -Linus
On Sun, May 15, 2011 at 08:42:49AM -0700, Linus Arver wrote:
On Sat, May 14, 2011 at 10:49:14PM +0100, Magnus Therning wrote:
Excellent, but what is the practice for [haskell], is profiling turned on for the binary packages?
Yes.
Quoting peti's comment (Thu, 31 Mar 2011 09:26:28 +0000) on haskell-cmdargs:
"...The Haskell packages that are distributed in [extra] are built with '-p' by default, but none of the AUR packages are. The reason for that is that [extra] packages are downloaded in binary form, so build times don't matter much for the average user."
I remember that, which is why I didn't ask about [extra], I asked about [haskell], i.e. the packages pre-compiled by ArchHaskell. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus I invented the term Object-Oriented, and I can tell you I did not have C++ in mind. -- Alan Kay
participants (5)
-
Linus Arver -
Magnus Therning -
Peter Hercek -
Peter Simons -
simons＠cryp.to