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

Wow, I really missed the 'big debate' :)

Anyways, here are some things that went on my mind going through the list:

- IIRC, some projects have build farms available... why is it we're not
using theirs to supplement ours?
I see here that GCC is willing to help any free software project:
http://gcc.gnu.org/wiki/CompileFarm
- Can we have distributed builds in non-Linux systems? If so, I think it
wouldn't be so hard to make the tinderboxes help each other in building
things
- 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. 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
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?
If we build after each commit, the CI service can push that commit that
is OK to the 'proofed' branch, and then only those commits would be
tested with others. A failed commit would mean an email to the author
and/or commiter. Only after the commit is fixed will it reach 'proofed'.
And we could build nightly from 'proofed'.
- I don't think we can expect developers to run a build before each
push, especially not with all the debug options enabled and the like.
This would massively slow them down IMHO. We have a relatively high rate
of commits. It does happen from time to time that a commits comes in
just after you do your ./g pull -r ; make.
So you have to repeat the process, and that isn't so nice.
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.

Just my 2 paise :)

Marc-André Laverdière
Software Security Scientist
Innovation Labs, Tata Consultancy Services
Hyderabad, India

On 10/07/2011 09:30 AM, Kevin Hunter wrote:
> At 6:28am -0400 Thu, 06 Oct 2011, Norbert Thiebaud wrote:
> > 2011/10/6 Norbert Thiebaud:
> > > I'll give it a shot...
> >
> > Not that I expect it to make a big difference... since most of the
> > compiles are ccached...
>
> As an nth data point on the matter, I've been using ccache for awhile,
> and my builds take longer.  Anecdotally (because I'm not focused on
> ccache specifically), I turned it off the other day, and my builds
> reduced from about 2 hours to 1h15m.*  For reference, my ccache size is
> 8G, but only 1.8 G has been used.  My hits at about 12,000 are about
> half of my misses.
>
> Cheers,
>
> Kevin
>
> * Both of those numbers are _very_ rough averages (created from memory
> of my "alias make='time make'" output), my builds compile in the
> background, at nice +19, on a puny dual-core 4G machine with a latent
> rotating HDD.  The majority of my builds are "./g pull -r; make" used
> for testing.  The less rough average is the "make distclean; ./g pull
> -r; make" workflow, which reduced a 3h30m compile to about 2h05m on the
> same hardware.
> _______________________________________________
> LibreOffice mailing list
> LibreOffice@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libreoffice