On 22 June 2015 at 19:58, Johannes Pfau via D.gnu <d.gnu@puremagic.com> wrote: > Am Mon, 22 Jun 2015 08:56:53 +0000 > schrieb "Iain Buclaw" <ibuc...@gdcproject.org>: > >> As the autotester seems to be broken indefinitely for the time >> being, I've been playing around with Travis for builds. >> >> https://travis-ci.org/ibuclaw/GDC/branches >> >> A couple of show stoppers I've been running into: >> - Time to build, run testsuite, run unittests exceeds quota (50 >> minutes) >> - Memory consumption exceeds quota (claims to be a hard 3GB) >> >> This is interesting, to speed up builds it might be considered >> logical to increase the number of parallel jobs, infact this >> conflicts directly with the memory consumption quota, meaning >> that the build needs to be carefully split up to run at different >> parallel levels depending on the memory used. >> >> What seems to be a total blocker is that I seem to be getting >> inconsistent results (in relation to out-of-memory errors) >> depending on which host the build is running on. > > Maybe drop them a mail if they would consider upgrading the quotas > for GDC. Regarding inconsistent results: If it's related to the build > environment using docker might help? >
I suspect that would require money. https://travis-ci.com/plans (Their production build servers allow up to 2 hours) The environment should be clean upon each new build. The problem I suspect is dependent on the current load of the host server where the VM / Sandbox is running. If it is already under high load (or not), this may drastically change the order of which sources are compiled in parallel. What I should do is split up the testsuite and unittests into two different environments, this will give us a better chance to complete in the short timeframe. On the topic of keeping memory down. What I'd like to do eventually is to integrate at least all glue structures into the GCC GC. It might also be possible to free up all front-end allocated memory too once we've finished generating all codegen. This is something that will need to be investigated (add it to our todo list?) > > BTW: I'd also like to run build-tests for arm and mingw in the future. > We could simply test if we can build the x86_64=>mingw/arm > cross-compilers. > > I'm currently preparing the last changes for crosstool-ng and once > that's done I'll publish the docker container to build the > gdcproject.org downloads. Then building the cross compilers will be as > simple as: > > docker run -v docker-shared:/home/build/shared -t > gdc/build-gdc /usr/bin/build-gdc build > --toolchain=x86_64-linux-gnu/gcc-snapshot/x86_64-w64-mingw32 Cool, I suspect you will still need to apply the memory hack for ld though as I have done. Iain.
