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

[Noel Grandin]

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
>

Disclaimer: http://www.peralex.com/disclaimer.html


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