[Libreoffice] oox/source/drawingml/customshapepresets.cxx is just too much for gcc

[Noel Grandin]

Following on to this, I suggest that it should not be hard to configure a Windows machine with 16G of RAM, and set aside
most of that memory as a RAM-drive. Then run the Windows build on the RAM-drive. That should speed things up.
I do that here for some of my builds, and it makes a massive difference.

In fact, I could probably get permission to host such a machine here at work, provided that the build slave does not
soak up too much network bandwidth (I'm in South Africa, bandwidth is expensive).

Regards, Noel Grandin

Noel Grandin wrote:
> It seems like Windows builds in particular would benefit from either (a) tons and tons of RAM or (b) an SSD.
> Who owns the hardware? Perhaps I (or the company I work for) can contribute to the cost of (a) or (b).
>
> Regards, Noel Grandin
>
> Norbert Thiebaud wrote:
>> 2011/10/7 Marc-André Laverdière <marc-andre at atc.tcs.com>:
>>> Wow, I really missed the 'big debate' :)
>> [...]
>>> - I agree that an email to 200 people is not super interesting. I think
>>> we should run git bisect to try building for every commit until we hit
>>> one that breaks, or build on each commit.
>> On linux and Mac we build fast enough that this is not a problem.
>> the reason we get to 200 people, is that one commit break things, and
>> 200 distinct people commit on top of that,
>> there is no way for a tinderboxes to decided who to send emails to.
>> you can't just send it to the original aithor because you can (and do)
>> get the seuqnce
>>
>> A push commit 1 that break
>> B push commit 2 that break
>> A push fix to the commit 1 breakage
>>
>> In that case how do you make a tinderbox realize that it should send
>> an email to B only ?
>>
>>> However, that is not so great
>>> if we  have commits for which the thing is fixed in the next commit. I
>>> am not expecting everyone to be comfortable with git rebase to the point
>> I am expecting them to be, that comes with the responsibility of being
>> a committer, and I do think that keeping the history bisectable is a
>> very good and important thing.
>>
>>> of merging commits all the time. But if we put such a policy in place,
>>> it would help people learn very very fast :)
>>> - Can we have some intermediary branch then? Or some 'proofed' branch?
>> That is call 'your local directory'
>>
>> [snipped section essentially describing 'gerrit' workflow. we are
>> working on that... ]
>>
>>> - I don't think we can expect developers to run a build before each
>>> push,
>> Yes we absolutely can expect that. it is actually a bare minimum !!!!!
>> pushing to the main repo is not a game of 'throw mud at the wall and
>> see what stick'
>>
>>> This would massively slow them down IMHO.
>> Well that would massively speed up everybody else.
>>
>>> We have a relatively high rate
>>> of commits.
>> about 50 a day, and that is not 50 distinct push
>>
>> the tinderboxes do 20 to 30 iteration a day
>> that is very close to an iteration per push.
>>
>>> It does happen from time to time that a commits comes in
>>> just after you do your ./g pull -r ; make.
>> So ? the issue is very rarely a conflict. the issue is new code not building.
>> So if you successfully did a make before git pull -r, that cover 95%+
>> of the breakages
>>
>>> So you have to repeat the process, and that isn't so nice.
>> Breaking master is not nice for the others.. because now they can
>> really check that thei change are ok, sometime they can't even get
>> to compile their change at all because to build can't even get there,
>> so they have to bring locally master back to a 'older good point'
>> (which require _them_ to 'repeat the proces'
>>
>>
>>> Now, if I have to build something a gazillion times slower before I can
>>> push, will I _ever_ be able to push? I'm not asking rhetorically by the way.
>> Then don't push every 5 minutes.
>> you only need make clean; make after a pull.
>> so pull -r. make clean; make
>> now you have a tree you can wok in. (provided master has not been
>> broken... see how that brokenness is contagious ?)
>> code, make, fix, make, fix, make.. commit, git status (to veryfy that
>> you did not miss anything in the commit, if necessary:git commit
>> --amend)
>>
>> Note that the 'make' above do not have to be global make... except for
>> a last one when you ar ready to pull -r, you can make the module you
>> changed (if it is a old-dmake module you need to build and deliver)
>>
>> Then pull -r
>> if you have conflict resolve them and definitely make
>> if you have no conflict, eyeball the change that got in and make a
>> call about the likelihood of a 'silent' conflict.
>>
>> At that point, if you want to be very safe: make clean/autogen/make
>> again... but if you don't an push, you still will be very unlikely to
>> have broken master.
>>
>> Push ... AND keep an eye on the tinderboxes. usually within 20 minutes
>> you should have the result of a tinderbox run with your pushed change
>> in it (except windows so far).
>>
>> http://tinderbox.libreoffice.org/MASTER/status.html
>>
>> Norbert
>> _______________________________________________
>> LibreOffice mailing list
>> LibreOffice at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/libreoffice
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20111007/121db9a6/attachment-0001.htm>