Re: [Libreoffice] oox/source/drawingml/customshapepresets.cxx is just too much for gcc
On 10/07/2011 03:51 PM, Norbert Thiebaud wrote: 2011/10/7 Marc-André Laverdière: Wow, I really missed the 'big debate' :) me too :- ) - 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 ! rebase, clean build Ok, rebase and build done on Linux, all ok. (with about 70 small patches of warning reduction) Then Push ... read mails, deleted some recurrent Windows tinderboxes mails - and read among others this one :- ) 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). look at my trash, see that this time I got also tinderboxes mails from MacOSX... Looked at log (since I have read this mail), did not understand from a possible guilty commit why this should break MacOSX compilation, try a "best guess" revert and see a green rebuild. And now fully convinced of the utility of tinderboxes, and of the need to take care of them in respect of other platforms that I do not have. Just to thanks tinderboxes maintainers Best regards Pierre-André ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] oox/source/drawingml/customshapepresets.cxx is just too much for gcc
On Fri, 2011-10-07 at 21:01 +0300, Tor Lillqvist wrote: > If you are building *on* Windows, use MSVC, is my opinion. That's my opinion as well. My concern centers around the expressed notion that, we should start using C99 features and not worry about a compiler (or compilers) that don't support it. That would effectively throw away the MSVC compiler. Kohei -- Kohei Yoshida, LibreOffice hacker, Calc ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] oox/source/drawingml/customshapepresets.cxx is just too much for gcc
On Fri, 2011-10-07 at 18:53 +0300, Tor Lillqvist wrote: > >> - 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 ! Gosh - lets discuss this in person at the conference :-) Comedic positions aside, I'm sure we can and need to plot some helpful course corrections to make life better for the long-suffering Windows compiler guys. The MingW cross-compilation work, for all it's potential hidden evils is letting me compile test for Windows, and catch lots of classes of problems in my VCL work at least - so hopefully we can catch and fix a whole class of basic errors with that work. HTH, Michael. -- michael.me...@suse.com <><, Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] oox/source/drawingml/customshapepresets.cxx is just too much for gcc
On Fri, Oct 7, 2011 at 7:13 PM, Kohei Yoshida wrote: > On Fri, 2011-10-07 at 11:30 -0500, Norbert Thiebaud wrote: >> On Fri, Oct 7, 2011 at 10:53 AM, Tor Lillqvist wrote: >> > >> > Flames about C99 being over ten years old already to /dev/null, >> > please. Voluntary technical standards that significant industry >> > participants choose to mostly ignore are mostly worthless. >> >> 'significant industry "particiapnt"' that chose to ignore standard are >> going to be stepped around... hence the mingw effort > > So, I have some concern with the direction we are going with this. > > Assuming that we will try to ditch MSVC in favor of mingw on Windows, > will we require people hacking on Windows to use mingw exclusively? > Also, does mingw do platform specific optimization as well as MSVC does? > Whatabout debugging tools? How will one debug LibreOffice on Windows? > I assume using Visual Studio as a debugging tool is out the window (no > pun intended)? > > Telling them to switch to Linux is not an option though. Not everybody > can make the switch, and some (many?) Windows developers want to stay on > Windows as the primary development platform. LibreOffice hackers are invited to come to my presentation in Paris to throw stones at me, as the title of one of my slides is "Why crosscompiling is evil". -- Jesús Corrius Document Foundation founding member Mobile: +34 661 11 38 26 Skype: jcorrius | Twitter: @jcorrius ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] oox/source/drawingml/customshapepresets.cxx is just too much for gcc
> Assuming that we will try to ditch MSVC in favor of mingw on Windows, Not MinGW on Windows, but MinGW as cross-compiler from Linux (or from some other Unix). If you are building *on* Windows, use MSVC, is my opinion. OOo thinks differently; they do/did try to support compiling using MinGW on Windows (and they haven't done any cross-compilation efforts at all AFAIK). > will we require people hacking on Windows to use mingw exclusively? I don't think we want to intentionally prevent the code from building with MSVC, even when at 4.0 we (hopefully) start distributing a cross-compiled build. > Also, does mingw do platform specific optimization as well as MSVC does? No idea, presumably not. > How will one debug LibreOffice on Windows? gdb? Yeah, horrible in many ways compared to Visual Studio. > I assume using Visual Studio as a debugging tool is out the window (no > pun intended)? I *think* I have heard people talk about some add-on trick to make Visual Studio understand also MInGW-generated debugging info. --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] oox/source/drawingml/customshapepresets.cxx is just too much for gcc
On Fri, 2011-10-07 at 11:30 -0500, Norbert Thiebaud wrote: > On Fri, Oct 7, 2011 at 10:53 AM, Tor Lillqvist wrote: > > > > Flames about C99 being over ten years old already to /dev/null, > > please. Voluntary technical standards that significant industry > > participants choose to mostly ignore are mostly worthless. > > 'significant industry "particiapnt"' that chose to ignore standard are > going to be stepped around... hence the mingw effort So, I have some concern with the direction we are going with this. Assuming that we will try to ditch MSVC in favor of mingw on Windows, will we require people hacking on Windows to use mingw exclusively? Also, does mingw do platform specific optimization as well as MSVC does? Whatabout debugging tools? How will one debug LibreOffice on Windows? I assume using Visual Studio as a debugging tool is out the window (no pun intended)? Telling them to switch to Linux is not an option though. Not everybody can make the switch, and some (many?) Windows developers want to stay on Windows as the primary development platform. Kohei -- Kohei Yoshida, LibreOffice hacker, Calc ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] oox/source/drawingml/customshapepresets.cxx is just too much for gcc
On Fri, Oct 7, 2011 at 16:34, Norbert Thiebaud wrote: > > To set-up a buildbot, clone contrib/buildbot and read > README.tinbuild2. if you have any question on that, please ask me. > Thanks Norbert, That doesn't sound like much bandwidth. I'll speak to the boss on Monday and see about getting the company to contribute the machine and some of my time. Regards, Noel Grandin ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] oox/source/drawingml/customshapepresets.cxx is just too much for gcc
> Note that with that kind of argument (if Microsoft doesn't 'like' it > then it is worthless), you'd still be stuck with IE6 Well if Firefox had not existed, or hadn't achieved any significant market share (on Windows), that might well had been the case... (Note that I am not claiming that would have been good.) And if my aunt had balls, she would be my uncle. --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] oox/source/drawingml/customshapepresets.cxx is just too much for gcc
On Fri, Oct 7, 2011 at 10:53 AM, Tor Lillqvist wrote: > > Flames about C99 being over ten years old already to /dev/null, > please. Voluntary technical standards that significant industry > participants choose to mostly ignore are mostly worthless. 'significant industry "particiapnt"' that chose to ignore standard are going to be stepped around... hence the mingw effort Note that with that kind of argument (if Microsoft doesn't 'like' it then it is worthless), you'd still be stuck with IE6 Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] oox/source/drawingml/customshapepresets.cxx is just too much for gcc
>> - 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 ! And on multiple platforms? Or at least with a bit of portability-enforcing options to gcc? Case in point: commit 1fc34c75a8a2356ed03c52ca839a7ad771c51ba1 , which breaks compilation with MSVC of some plain old *C* files in soltools/javadep. Please, use cppcheck only on C++ files. C is not C++. gcc with its default settings is not a proper *C89* compiler. Flames about C99 being over ten years old already to /dev/null, please. Voluntary technical standards that significant industry participants choose to mostly ignore are mostly worthless. --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] oox/source/drawingml/customshapepresets.cxx is just too much for gcc
On Fri, Oct 7, 2011 at 9:21 AM, Noel Grandin wrote: > > 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). That would be great... The biggest bandwidth is to send an email with the tar.gz build log (typically 300 to 400 KB ) to the tinderbox server, after each build Bandwidth to keep the git repo up-to-date should not be too big, but it is hard to quantify and can vary. To set-up a buildbot, clone contrib/buildbot and read README.tinbuild2. if you have any question on that, please ask me. Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] oox/source/drawingml/customshapepresets.cxx is just too much for gcc
On Fri, Oct 7, 2011 at 9:08 AM, 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). It is not clear that that would be enough to bring the windows build time down to a practical value. I would be reluctant to just throw money at the problem without any idea of what would be the impact. Of course if someone can demonstrate a setup that achieve a substantial speed-up (we are talking at least x10 compare to now), then that would be different. Bear in mind also, that the direction right now is to move to a mingw-based build, which has build time comparable to linux or macosx... the problem is that mingw windows build would be ABI incompatible with the current windows build, so that has to wait for libreoffice 4.0 And of course donation are most welcome either way: http://www.documentfoundation.org/contribution/ We will need them to build up a gerrit/jenkins buildbot/testbot infrastructure :-) Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] oox/source/drawingml/customshapepresets.cxx is just too much for gcc
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 : >>> 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
Re: [Libreoffice] oox/source/drawingml/customshapepresets.cxx is just too much for gcc
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 : >> 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@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/libreoffice > Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] oox/source/drawingml/customshapepresets.cxx is just too much for gcc
2011/10/7 Marc-André Laverdière : > 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@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
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 > ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] oox/source/drawingml/customshapepresets.cxx is just too much for gcc (rant inside)
On Thu, 06 Oct 2011 13:42:52 +0200
Jan Holesovsky wrote:
> On 2011-10-06 at 10:58 +0200, Bjoern Michaelsen wrote:
>
> > Also newcomers (without procmail rules) who finally got their
> > first commit in are scared away from the project, because these
> > mails are telling them they either got it wrong (which is what a
> > first commiter would suspect) or others around him are careless are
> > not encouraging at all.
>
> Just a small correction, we are mailing people pushing the commits,
> not the authors, so this is fine.
Thanks for the correction, but I dont think it changes much about my
point: Newcomers are already reluctant to get commit access ("Oh, I
rather just send patches until I feel more at home" is heard quite
often) and getting the full nine yards on their first selfpushed commit
isnt encouraging either.
Best,
Bjoern
--
https://launchpad.net/~bjoern-michaelsen
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] oox/source/drawingml/customshapepresets.cxx is just too much for gcc (rant inside)
Hi Bjoern, On 2011-10-06 at 10:58 +0200, Bjoern Michaelsen wrote: > Also newcomers (without procmail rules) who finally got their first > commit in are scared away from the project, because these mails are > telling them they either got it wrong (which is what a first commiter > would suspect) or others around him are careless are not encouraging > at all. Just a small correction, we are mailing people pushing the commits, not the authors, so this is fine. Regards, Kendy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] oox/source/drawingml/customshapepresets.cxx is just too much for gcc
Hi Tor, On Thu, 6 Oct 2011 11:18:24 +0300 Tor Lillqvist wrote: > The only solutions I see are: > > 1) Either we should get some really really bad-ass Windows tinderbox, > *and* make it use ccache (i.e. investigate whether kendy's port of an > old ccache version really works correctly, or re-port a current ccache > to support MSVC). 1a) Or we use gerrit to coordinate tinderboxes, so that the moderately bad-add Windows tinderbox only tests stuff that succeeded on a fast Linux tinderbox. After all, quite a lot of stuff will break on both platforms and there is no use in testing on a slow one what has already failed on a fast one. > Obviously "we" (for some value of "us") can't enforce that on > volunteers, only bosses can on their paid developers ;) Just an additional note: In general, I fully expect volunteers to fix breakers they introduced on _any_ platform. That is the only way it can work sensibly. However with our current setup that is more than volunteers can do, which is why we need to change the situation. To get volunteers to fix breakers they introduced, we need to make sure it is a rare occurrence with clearly assigned responsibility. Mailing 200 people "one of you broke master on Windows" isnt helping anyone. Best, Bjoern -- https://launchpad.net/~bjoern-michaelsen ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] oox/source/drawingml/customshapepresets.cxx is just too much for gcc (rant inside)
Hi Tor, all, On Thu, 6 Oct 2011 09:01:06 +0300 Tor Lillqvist wrote: > Seriously, is it really that awful if a few tinderboxes are red for > some days? Yes, it is. Reasons follow below. > Some of them are red for weeks. IMHO we should do something about that too. > Is just bluntly reverting the right way to solve problems? If it is, > will have to remember that. At least for "breaks all platforms, cant possibly be right"-commits it is. If that happens the commiter/pusher did not do his due diligence and shouldnt complain. As a rule of thumb I personally expect every push to be tested on one platform at least(*). If it obviously was not, I have no qualms against a revert -- actually I would expect others to do the same (unfortunately some commits can even be fixed by that because of interdependencies with other changes). Reasons why tinderboxes red for a week are bad: - Whatever we had in people trying their first build this week are gone and will likely never come back. - It makes certain work almost impossible. I asked Fridrich about testing feature/kill-set_soenv on cygwin, but that has to wait until the one commit in the month where the windoze tinderbox is green again. - We do not get any early warnings by people testing nightlys as there are none. - While the tinderboxes are red for sustained periods of time, we are flying blind. Commits breaking things additionally in interesting new ways sneaks in and pile up shadowed by the first breaker. - Sustained "tinderbox is red"-periods are blackboxes for "git bisect". - There is a moral hazard: When you get twenty tinderbox breaker mails a day you just ignore them (or procmail them with the same result). Also newcomers (without procmail rules) who finally got their first commit in are scared away from the project, because these mails are telling them they either got it wrong (which is what a first commiter would suspect) or others around him are careless are not encouraging at all. - A break on master causes lots of duplication of work as many people are working on a fix and once they push their fixes likely conflict and cause even more trouble. The most recent example is almost poetry: A commit pushes an unbalanced ifdef in scp2: http://cgit.freedesktop.org/libreoffice/core/commit/scp2/source/ooo/file_library_ooo.scp?id=5bd2890a56125d391b42f34d51e2e0c57b0a80b0 this of course breaks the build for everyone. Lots of people get hit by it and start debugging and searching for the problem -- among them Caolan and I. Caolan pushes his fix first: http://cgit.freedesktop.org/libreoffice/core/commit/scp2/source/ooo/file_library_ooo.scp?id=a2623000c16d9f02bb945559a91d5bd76651772a I too fix the issue (as I pulled two commits before Caolans fix), test it and pull -r/push it back: http://cgit.freedesktop.org/libreoffice/core/commit/scp2/source/ooo/file_library_ooo.scp?id=d2f633c5464fd4339e9e804c97596a78bfa58e62 Note that the rebase silently resolved the conflict: "Remove one #endif? Roger, Wilco." Now two #endifs got removed and master is broken _again_ until: http://cgit.freedesktop.org/libreoffice/core/commit/scp2/source/ooo/file_library_ooo.scp?id=e944e135bc157d092532fff0829390fa7d4fa958 which also collided midair _again_ with the same fix from Fridrich (which he had to throw away, because I was faster this time). As result master was broken for half a day, lots of useless communication on IRC about it and lots of wasted resources. Now this might seem like a rare example but it likely isnt: - A lot of fixes can be mutually exclusive and still apply be without conflict -- it does not need the poetry of applying the exact same fix twice for that. - Even if the fixes collide on rebase, the additional work and wasted time is already gone. With a project this size and these numbers of commits this is bound to happen again and again rather sooner than later. This ain't Kansas anymore, Toto. I dont want to single anyone out here, this can (and will, given some time) happen to anyone with our current setup. But please, please be aware of the consequences until we have a better one. Finally: This is a prime selling point why gerrit with tinderboxes testing commits _before_ they hit master is a Good Thing(tm), but I think this point is painfully obvious now, isnt it? Best, Bjoern (*) Do I do that for a those mythological "cant possibly break anything"-commit right now? No, not a build from scratch for every one of them as chances are good that somebody else pushes while I build and I would need to rebase again anyway. But if I botch such a commit I expect the exact blunt reversal you talk about if I am to slow to react in fixing it myself. My little broken commit can possibly be more important than the health of master for everyone. -- https://launchpad.net/~bjoern-michaelsen ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/m
Re: [Libreoffice] oox/source/drawingml/customshapepresets.cxx is just too much for gcc
The only solutions I see are: 1) Either we should get some really really bad-ass Windows tinderbox, *and* make it use ccache (i.e. investigate whether kendy's port of an old ccache version really works correctly, or re-port a current ccache to support MSVC). 2) Or, we should have our developers mainly work on the "difficult" platforms, i.e. Windows, and to some extent MacOSX, so that they notice themselves when code they are writing will cause problems on these platforms. Only people mainly doing distro packaging would continue to work on Linux. Obviously "we" (for some value of "us") can't enforce that on volunteers, only bosses can on their paid developers ;) 3) Or, we should jump to 4.0 directly, and support only cross-compilation to Windows. (Yes, that means a lot of work needs to be done to avoid too many regressions in the form of missing features.) Obviously I am not really expecting you to take alternative 2 seriously. --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] oox/source/drawingml/customshapepresets.cxx is just too much for gcc
On Thu, Oct 6, 2011 at 1:01 AM, Tor Lillqvist wrote: >> because oox/source/drawingml/customshapepresets.cxx, a 4MB source, >> made gcc blow-up both on Mac and on Gentoo > > The horror! The horror! > > Seriously, is it really that awful if a few tinderboxes are red for > some days? That particular one get Linux and Mac to die due to a gcc abend...it is not like it is missing an include of some strategically placed #ifdef > Some of them are red for weeks. And that is very bad... hopefully with mingw the tinderbox iteration time will be in part with other platform and in the 15-20 minutes range. the current windows tinderbox itarate at best in 10 hours or so. it makes it completely unpractical to monitor's one's commit and to identify which commit is responsible of a breakage. > Is just bluntly reverting > the right way to solve problems? If it is, will have to remember that. that particular revert was not 'blunt'. that particular commit did not just make the build failed, it made the box that tried to build fail or at least suffer badly. on Mac, thanks to the fact that gcc ran as a 32 bit process it died before doing much damage to the rest of the system. on my linux, it was happily consuming 7+GB of memory by the time I manually kicked it...a commit that break the build is one thing, one that essentially DOS the tinderboxes are another. Many times, whenever I can, I try to fix the problematic commit rather than reverting. and the work is not lost... it is right there in git. if you find of a way to make it work, please, by all means do so. but to answer your more general question: yes red tinderboxes are bad, very bad. because it has a run-away effect: When master is broken, you can't check your work properly, so you increase the odd of yourself pushing a broken commit leading to an even more broken master; In the mean time tinderbox are not able to produce daily build... which means that QA cannot do their part to find bug early. Yep it is that bad on windows... and yeah we haven't been able to produce a daily build for it in weeks... but that is no reason to make that the 'standard'. Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] oox/source/drawingml/customshapepresets.cxx is just too much for gcc
> because oox/source/drawingml/customshapepresets.cxx, a 4MB source, > made gcc blow-up both on Mac and on Gentoo The horror! The horror! Seriously, is it really that awful if a few tinderboxes are red for some days? Some of them are red for weeks. Is just bluntly reverting the right way to solve problems? If it is, will have to remember that. --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] oox/source/drawingml/customshapepresets.cxx is just too much for gcc
I reverted c9f9b6723b40279716b1e34c1441a33e60cceb58. e36f591dfeb89fded172f4770157bc6cb6dc7454. because oox/source/drawingml/customshapepresets.cxx, a 4MB source, made gcc blow-up both on Mac and on Gentoo The compiler churned on it for 20 minutes or consumming huge amount of memory ( as in GBs)... and finally blow-up with memory error. Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
