When I emerge PyQt, compiling the first file: g++ -c -pipe -march=pentium3 -O2 -pipe -fomit-frame-pointer -fPIC -O2 -Wall -W -D_REENTRANT -DQT_NO_DEBUG -DQT_THREAD_SUPPORT -I. -I/usr/include/python2.3 -I/usr/qt/3/include -I/usr/X11R6/include -o sipqtpart0.o sipqtpart0.cpp takes a very long time (more than 15 minutes) on a 500MHz PIII machine and produces a high load of more than 12. This is caused by the "-c" flag used when calling configure.py in the ebuild. From the PyQt FAQ: "Why does compilation take so long? PyQt is big, and comprises many source files. However, the configure.py script takes a -c command line flag which concatenates each module's C++ source files into one large file. If your compiler and system are capable of compiling large C++ source files then compilation times can be reduced dramatically. Using this flag PyQt will compile in 10 minutes on a Linux based 750MHz 256M PIII system." Please don't do this. make it at least a USE flag. I'd also guess that compiling multiple small files instead of a large one would be better with regard to distcc. Reproducible: Always Steps to Reproduce: 1.emerge PyQt Actual Results: Load increases above 12, system isn't really useable any more. Expected Results: Load shouldn't increase to that degree, system should remain useable, as it is w/o the -c option.
The concatenation of the c++ files speeds up compilation for the majority of systems. Compiling the whole PyQt takes real 8m57.063s user 6m19.340s sys 0m47.470s on my 1.2Ghz Duron (and this is a slow machine nowadays), compared to real 88m6.551s user 71m48.460s sys 4m52.640s when having concatenation disabled. Also the load wasn't lower in the latter case (rather a bit higher, but I used the system while testing). Did you made such a comparison on your machine (ccache disabled)? I really dislike adding new use flags, if there's not a very good reason for this. Switching concatenation of when distcc is in Features would be possible, but I would like to see some numbers, which justify this. >Load increases above 12, system isn't really useable any more. That's not a good reason. You can always (re-)nice single processes and we've the PORTAGE_NICENESS variable for this.
Um, the 8 minutes were _cached_ of course, but uncached it's still below 30 minutes
I'm not sure I care about the taking forever (it is qt afterall...) and I can't replicate the high load (1.2 load average during compile). BUT it would be real nice for sanity's sake to insert a "We are compiling now you just may not see anything for the next few (seconds, minutes, hours etc) after this message: >>> md5 src_uri ;-) PyQt-x11-gpl-3.12.tar.gz >>> Unpacking source... >>> Unpacking PyQt-x11-gpl-3.12.tar.gz to /var/tmp/portage/PyQt-3.12/work >>> Source unpacked. My reasoning is I just tried recompiling this but I thought I had hung in a real weird way since I didn't get *ANY* output.
Of course I did renice the cc1plus process to the lowest priority possible, but that didn't help. And, if you don't want to introduce a new USE flag, that's ok for me, but an ebuild _should_ IMHO prefer stability over speed. I can reproduce this behaviour on this type of machine and the fix is to avoid concatenation.
i am still in this situation, my computer hangs for about 4 hours (!) when i try to copile the kdebindings (and it was ended in a bug...) i was so happy... my computer is a 2,8 GHz P4M (acer travelmate 634LC). every time if i compile a kde app, or part of the kde, my computer hangs a lot of time. (hang = the mouse not moving, the keyboard not working - i cant change to the second console (alt+control+f2), the clock on the right on the kde panel dont change, it seems like a hardware crash, but the winchester led is blinking)
Another problem is that the compilation of PyQt takes a lot of memory. On a medium-end system (I got 256Mb RAM, minus 64 eaten by the videocard), the whole RAM and swap are eaten, and the process is killed by kernel. This is quite troublesome, so it would be nice if the flag could be deactivated.
>but an ebuild _should_ IMHO prefer stability over speed. Dirk, the stability issue is on your side. I tried a couple of configurations and not even with ~90 MB left for compilation (+300 MB swap) I could reproduce your problems. Also one usually compiles on another box, if the target is that antiquated. T
>but an ebuild _should_ IMHO prefer stability over speed. Dirk, the stability issue is on your side. I tried a couple of configurations and not even with ~90 MB left for compilation (+300 MB swap) I could reproduce your problems. Also one usually compiles on another box, if the target is that antiquated. Tóth: KDE needs a lot of ressources for compilation and of course it swaps a lot without enough ram. 4 hours or more for the whole kdebindings package sounds reasonable for your box. >On a medium-end system Oliver - that's low end. Who still sells a box with 256MB ram only is simply an asshole. I changed the latest PyQt ebuild. Do 'FEATURES=distcc emerge PyQt' and you're rid of the flag.
