I've noticed that cabal install now has a -j option for parallel builds, and has to be told how many builds to run in parallel. This seems strange - most parallel capable systems run in parallel by default, with one process/thread per core. Why is cabal different?
On Sun, May 5, 2013 at 9:44 AM, harry
I've noticed that cabal install now has a -j option for parallel builds, and has to be told how many builds to run in parallel. This seems strange - most parallel capable systems run in parallel by default, with one process/thread per core. Why is cabal different?
Not that different; make doesn't run parallel by default either (see make -j). -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
On Sun, May 05, 2013 at 06:10:25PM +0000, gs wrote:
Brandon Allbery
writes: Not that different; make doesn't run parallel by default either (see make -j).
Does cabal -j also suffer from interleaved output?
No; when the -j flag is turned on it uses an abbreviated output format that just tells you *what* it is doing (downloading XYZ package, configuring foo, building baz...) but not the details, with the details going to a separate log file for each package. There may soon also be a way to use it with hydra-print which could be nice.
And will it be possible to set e.g. -j12 as the default?
Yes, edit your ~/.cabal/config and add/uncomment the line jobs: 12 -Brent
Brent Yorgey wrote:
No; when the -j flag is turned on it uses an abbreviated output format that just tells you *what* it is doing (downloading XYZ package, configuring foo, building baz...) but not the details, with the details going to a separate log file for each package. There may soon also be a way to use it with hydra-print which could be nice.
So if there aren't any downsides, why not make it the default?
For sure one downside is that the output is less verbose (you wouldn't
see anything otherwise) and buffered; in case of an error only last 10
or so lines are printed which makes it harder to debug. When I
encounter such problem I always rerun the build without -j to see the
actual problem in full.
Unexperienced users would have much problem with this.
Best regards,
Krzysztof Skrzętnicki
On Mon, May 6, 2013 at 8:14 AM, Guy
Brent Yorgey wrote:
No; when the -j flag is turned on it uses an abbreviated output format that just tells you *what* it is doing (downloading XYZ package, configuring foo, building baz...) but not the details, with the details going to a separate log file for each package. There may soon also be a way to use it with hydra-print which could be nice.
So if there aren't any downsides, why not make it the default?
_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners
On Wed, May 29, 2013 at 09:01:45AM +0000, harry wrote:
Brent Yorgey
writes: Yes, edit your ~/.cabal/config and add/uncomment the line
jobs: 12
I just tried that with the new HP, and got cabal: Command.optionToFieldDescr: feature not implemented
What version of cabal do you have? I.e. what is the output of cabal --version ? -Brent
participants (6)
-
Brandon Allbery -
Brent Yorgey -
gs -
Guy -
harry
-
Krzysztof Skrzętnicki