On 04/08/2014 16:20, Dmitri Gribenko wrote:> On Mon, Aug 4, 2014 at 2:20 PM, Dan Liew <dan at su-root.co.uk> wrote: >>>> Second, is there a simple way to test the builder and config before I >>>> commit >>>> it? >>> >>> I am afraid not. >>> >> >> But there is a ugly (and certainly not simple) way to partially test the >> builder that I mentioned recently [1]. > > Nice write-up! > >> I say partially because I ended up removing all the builders apart from my >> own. >> >> @Dmitri - Has anyone considered reorganising zorg so it is easier to test a >> builder locally? > > I am not aware of such effort. However, it would be great to be able > to easily set up a buildmaster locally. This will probably facilitate > further refactorings of zorg code. Currently developers tend not to > touch it because they can not run it.I commonly test my changes with a 'hacked' buildbot where references to non-existing files are removed and buildslave passwords are hardcoded. It would be great if we could instead have a 'testing' mode, where the user can provide a table with buildslave names and passwords and the buildbot just takes this to accept its buildslaves. Cheers, Tobias
Dmitri, Great, thanks! Can I assume that cmake and a relatively recent clang are already installed? I can add building llvm/clang to the builder, but the fewer CPU cycles the better. Other-Dan, Thanks. That write-up really helped. The process still sucks, but at least I wasn't stumbling blindly. - Dan On Mon, Aug 4, 2014 at 7:47 AM, Tobias Grosser <tobias at grosser.es> wrote:> On 04/08/2014 16:20, Dmitri Gribenko wrote: > >> On Mon, Aug 4, 2014 at 2:20 PM, Dan Liew <dan at su-root.co.uk> wrote: >> >>> Second, is there a simple way to test the builder and config before I >>>>> commit >>>>> it? >>>>> >>>> >>>> I am afraid not. >>>> >>>> >>> But there is a ugly (and certainly not simple) way to partially test the >>> builder that I mentioned recently [1]. >>> >> >> Nice write-up! >> >> I say partially because I ended up removing all the builders apart from >>> my >>> own. >>> >>> @Dmitri - Has anyone considered reorganising zorg so it is easier to >>> test a >>> builder locally? >>> >> >> I am not aware of such effort. However, it would be great to be able >> to easily set up a buildmaster locally. This will probably facilitate >> further refactorings of zorg code. Currently developers tend not to >> touch it because they can not run it. >> > > I commonly test my changes with a 'hacked' buildbot where references to > non-existing files are removed and buildslave passwords are hardcoded. > > It would be great if we could instead have a 'testing' mode, where the > user can provide a table with buildslave names and passwords and the > buildbot just takes this to accept its buildslaves. > > Cheers, > Tobias > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140804/e0ccb3ef/attachment.html>
Dmitri Gribenko
2014-Aug-05 06:14 UTC
[LLVMdev] [cfe-dev] zorg config for libc++/libc++abi
On Tue, Aug 5, 2014 at 1:02 AM, Dan Albert <danalbert at google.com> wrote:> Dmitri, > > Great, thanks! Can I assume that cmake and a relatively recent clang are > already installed? I can add building llvm/clang to the builder, but the > fewer CPU cycles the better.There is clang 3.5 installed from Debian packages. We could also add another builder with a trunk clang that we update manually. There is also cmake, ninja and ccache. Please take a look at other builders on the same host to set up ccache env vars correctly, if this would benefit libc++. But IIRC there are only a few translation units in libc++, so maybe it is not worth it. Dmitri -- main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if (j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/
On 4 August 2014 15:47, Tobias Grosser <tobias at grosser.es> wrote:> On 04/08/2014 16:20, Dmitri Gribenko wrote: >> >> On Mon, Aug 4, 2014 at 2:20 PM, Dan Liew <dan at su-root.co.uk> wrote: >>>>> >>>>> Second, is there a simple way to test the builder and config before I >>>>> commit >>>>> it? >>>> >>>> >>>> I am afraid not. >>>> >>> >>> But there is a ugly (and certainly not simple) way to partially test the >>> builder that I mentioned recently [1]. >> >> >> Nice write-up!Thanks but Mikael Lyngvig deserves most of the credit here. I would not of got very far without his blog post.>>> @Dmitri - Has anyone considered reorganising zorg so it is easier to test >>> a >>> builder locally? >> >> >> I am not aware of such effort. However, it would be great to be able >> to easily set up a buildmaster locally. This will probably facilitate >> further refactorings of zorg code. Currently developers tend not to >> touch it because they can not run it. > > > I commonly test my changes with a 'hacked' buildbot where references to > non-existing files are removed and buildslave passwords are hardcoded. > > It would be great if we could instead have a 'testing' mode, where the > user can provide a table with buildslave names and passwords and the > buildbot just takes this to accept its buildslaves.This should probably be discussed in a different thread. I'll create one on llvmdev. Thanks, Dan
On 4 August 2014 15:47, Tobias Grosser <tobias at grosser.es> wrote:> I commonly test my changes with a 'hacked' buildbot where references to > non-existing files are removed and buildslave passwords are hardcoded.I just have my own local build master. It's not that hard to set up. cheers, --renato