On Monday 29 June 2009, Lubos Lunak wrote:
I don't see the difference to a kde4-filesystem (or name it kde4-macros) There is a huge difference : After I change a macro, it doesn't trigger a rebuild of everything out there :).
Which is good for debugging, but bad for fixing issues. if you fix something, you want the fix to propagate :)
Maybe if I knew buildservice better when I started, I would have done this using conditionals (although they're not exactly simple to use together with macros), but I actually consider my current setup quite elegant. Instead of standard build repositories I have a setup of special build repositories created using home:llunak:distro, they provide everything needed for the cross-distro magic and it's up to the packager to use them or the standard build repos.
I'm not sure, I consider it hackish, but thats my feeling.
Ok, I'll try adding them to UNSTABLE first, just in case. If it doesn't become more unstable after that, I'll move it to K:Factory.
I have a script for cleaning up the file lists anyway according to macro names, so you don't have to do that, I can just run it.
Makes sense for me, and can't hurt. I don't know what %{_smp_mflags} is. wouldn't it be good enough to build it serially? It is (e.g.) -j2. People with more cpus/cores presumably have also more memory. And I don't want to wait unnecessarily while building locally.
yep,but a machine with 64 cores will still die on meinproc.
Sure. note that I tried to implement this already via icecream, assuming that you build via icecream. If not, you should </shameless plug>. I don't see how icecream can help me here. Generating documentation is not compilation, the limiting here could be only done by make (boy, do I miss unsermake :-/ ). Oh, you mean meinproc via icecream? Hmm ... interesting idea.
no, icecream has the feature to serialize anything that is not a compile job. e.g, if you do ln -s /opt/icecream/bin/icecc /opt/icecream/bin/meinproc4 and use meinproc4 (adjusting $PATH), then it will make sure that meinproc4 is not run in parallel at all, while other things still parallelize as needed. Greetings, Dirk -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org