Gentoo Archives: gentoo-dev

From: Duncan <1i5t5.duncan@×××.net>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] Re: [RFC] RESTRICT=parallel for builds that can't be executed in parallel
Date: Wed, 14 Apr 2010 07:07:30
In Reply to: Re: [gentoo-dev] [RFC] RESTRICT=parallel for builds that can't be executed in parallel by Brian Harring
1 Brian Harring posted on Tue, 13 Apr 2010 23:10:16 -0700 as excerpted:
3 > RESTRICT=parallel is basically a big lock that forces building to go
4 > down to one specific build/merge job- it's not at all fine grained. That
5 > said, I'm not convinced it's worth actually *trying* to be fine grained.
6 >
7 > Stuff that needs this 'lock', if you look at it from the purely academic
8 > angle is broken. The pkgs in question should be buildable without
9 > modifying the livefs.
10 >
11 > From the pragmatic angle, fixing some of those packages is a pretty huge
12 > endeavour hence this lock existing. I see no reason to encourage the
13 > usage of this lock by making it more fine grained, either.
15 What examples of the problem do we have, other than xorg-server due to
16 eselect opengl?
18 For just xorg-server, killing parallel seems like a rather frustrating and
19 indeed broken solution (especially for folks who prefer to run freedomware
20 and thus have only the X11/mesa opengl version on their system anyway, so
21 forcing non-parallel is an exercise in uselessness). If it's the only
22 one, at /least/ only forcing non-parallel if the eselect opengl actually
23 changes the selected opengl would seem reasonable.
25 But if there's other non-contrived examples around, getting a couple of
26 them on the table should I think clarify our potential usage constraints
27 somewhat.
29 --
30 Duncan - List replies preferred. No HTML msgs.
31 "Every nonfree program has a lord, a master --
32 and if you use the program, he is your master." Richard Stallman