On Thu, Jul 06, 2006 at 11:58:28PM +0200, Adam Borowski wrote: > On Wed, Jul 05, 2006 at 08:23:00PM +0200, Wouter Verhelst wrote: > > On Mon, Jul 03, 2006 at 03:04:14PM +0200, Adam Borowski wrote: > > > On Sun, Jul 02, 2006 at 11:57:50AM +0200, Wouter Verhelst wrote: > > > > Additionally, it puzzles me how you think a maintainer will be able to > > > > accurately predict how much RAM a certain build is going to use. There > > > > are so many variables, that I think anything but 'this is the fastest > > > > way to build it on my machine' is going to be unfeasible. > > > > > > Let's say: > > > program X consist of a number of C files; it seems like compiling > > > every file takes around 24MB, > > > > Like I said, there's just too many variables. Also, I wouldn't be > > interested in figuring out how much RAM the build takes if I were to > > maintain a package like, say, X or so. > > No one forces you to do so. No one even said a word about making > concurrency mandatory. It's just a way to make builds faster on > machines that are beefy enough (ie, virtually all). > > > You're not convincing me that you can indeed accurately predict for > > every compiled language out there how much RAM you're going to need > > during the build. > > So what? If you're not sure, you simply don't provide your > prediction. And with a huge safety margin, you would have to be > MALICIOUS to make a mistake. > > > Before you've proven that this is indeed possible, I don't think > > there's much point in this whole exercise; otherwise there > > *is* going to be a problem with you overloading build machines, and > > *you will* get bugs filed about that (from me, at the very least). > > Here, you got a piece of working code, is that not a good enough > proof? Tell me how exactly a build using 4 processes using ~24MB > each overloading a build machine which has 512+MB ram. And builds > which do require 1+GB of memory, well, simply are not going to use > any concurrency. > > And note that the system I propose actually _limits_ concurrency in > some cases. The whole thread started with gem packages choking the > m68k build. It's a big package, and the maintainer rightfully > thinked that it is completely useless on small arches.
Err, AIUI, ruby gems are a way to automatically install extras to a running ruby environment, much in the same way that the CPAN module is used for Perl. I fail to see why this would be "completely useless" on smaller architectures. If you want to use ruby there, you may want to use gem. -- Fun will now commence -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
