zorg config for libc++/libc++abi

Project Infrastructure LLVM Dev List Archives
1

Hi all,

I’m trying to add builders to zorg for libc++ and libc++abi. I think I have the builder right, but I have a few questions.

First, how do I know which build slaves to use? Is it okay to just pick a few, is there some policy defining which are fair game, or do I need to add a new one?

Second, is there a simple way to test the builder and config before I commit it?

Here’s my first attempt: https://github.com/DanAlbert/zorg/commit/2ff832f710982c487174e507bb2a2704248fe821

Thanks,
Dan

2

Hi all,

I'm trying to add builders to zorg for libc++ and libc++abi. I think I have
the builder right, but I have a few questions.

First, how do I know which build slaves to use? Is it okay to just pick a
few, is there some policy defining which are fair game, or do I need to add
a new one?

I would be happy to host them. I have a large machine running debian
sid x86_64 and ubuntu 14.04 x86_64 VMs.

Second, is there a simple way to test the builder and config before I commit
it?

I am afraid not.

Dmitri

3

Hi all,

I'm trying to add builders to zorg for libc++ and libc++abi. I think I have
the builder right, but I have a few questions.

First, how do I know which build slaves to use? Is it okay to just pick a
few, is there some policy defining which are fair game, or do I need to add
a new one?

I would be happy to host them. I have a large machine running debian
sid x86_64

This one has the name 'gribozavr4'.

and ubuntu 14.04 x86_64 VMs.

This one is not connected yet. (Will have the name 'gribozavr5' probably.)

Dmitri

4

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].

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?

[1] http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-August/075287.html

5

> 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.

Dmitri

6

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

7

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
8

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

9

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

10

I just have my own local build master. It's not that hard to set up.

cheers,
--renato