[DOCS] Review requested: How to Setup an Arch Linux Buildbot

Mikael Lyngvig mikael at lyngvig.org
Fri Nov 22 12:52:23 PST 2013


Hi Renato,

Thanks for your comments!  If I don't write anything about a specific
issue, I'll be changing it to match your suggestion.

1. I'm not sure I need the swap file at all after I switched to using Gold.
 I guess I should try it out before I submit the document to be committed.
 The swap file will only be used if needed, so it shouldn't slow down the
build unless it is really needed.  How do you use Gold in the proper way?
 LD=ld.gold cmake ...?

2. I must admit that I am blissfully unaware of CMake supporting CCache?
 What do I need to to use CCache the proper way? :-)  Is it only a matter
of using: CC="ccache gcc" CXX="ccache g++" cmake ...?  Besides, I believe
the given configuration uses Autoconf and not CMake.  It might be better to
use CMake, though.

3. I am aware that there's already a document on how to set up a buildbot
slave, but I am aiming for a single one-shot document that describes all
steps in a single document.  I'll put in a link and consider if the
existing document needs updates (which I don't think).  My plan is actually
to make all in all three of these walk-through documents: Arch Linux,
Debian, and Windows.  After that, I feel people should have sufficient info
to set up a buildbot slave without further instructions.

4. I have already killed the epilogue - I sort of knew it didn't belong in
there, but wanted to avoid that suggestions and ideas are lost because
people don't want to sign up for LLVM-dev just to submit a small
correction.  I'll write that people can submit enhancements, etc., to
LLVM-dev instead.


-- Mikael






2013/11/22 Renato Golin <renato.golin at linaro.org>

> Hi Mikael,
>
> Sorry for the delay, I was out of action for a few days...
>
> Overall looks good, thanks for working on this, it really is important to
> have that info out there.
>
> You'll also need to link your document from a more centralized page. Scan
> the root (llvm.org/docs) and find the best place to put this, possibly
> besides other ARM docs, or buildbots, and add a link to your document from
> there.
>
> Some comments on the text:
>
>
> =-=-=-=-=-=-=-= Text:
> The ODROID-XU comes with 2 GB of RAM, which is just a tad too little to
> build
> LLVM as the linking process requires up to 4 GB of virtual memory to
> complete.
> Create and mount a swap file using the steps below:
>
> ++ I don't create swap files, as the build can take considerably longer.
> But in the case of ODroid, using "make -j4" might push the limits of the
> 2GB.
> ++ I don't object to this section, but would be good to explain that the
> -j4 is the reason, and that swap impacts quite a lot the build time
>
> -- Alternatively, you could use Ninja Pools (
> http://martine.github.io/ninja/manual.html#ref_pool) but we'd need to
> enable that by default on CMake to be effective without re-editing the
> Ninja file every time the CMake runs.
>
>
> =-=-=-=-=-=-=-= Text:
> You should create a boot time script to do the above as the change seems to
> be lost after a system reboot (see the chapter on *Starting the Buildbot
> Slave at Startup* for a sample init script).
>
> ++ The changes don't propagate between boots (ie. you may drop the "seems
> to")
> ++ Would be good if you could share how you did it, too. ;)
>
> =-=-=-=-=-=-=-= Text:
>    pacman -S base-devel
>    pacman -S subversion
>    pacman -S ccache
>    pacman -S buildbot
>    pacman -S htop
>
> ++ You forgot to add "pacman -Syu" which is required for the above
> commands to work
> ++ Also, you could have added all packages into one command, to relieve
> the package management system to re-set the package structure every time
>
> =-=-=-=-=-=-=-= Text:
> We're going to enable ``ccache`` globally by adding symlinks for ``gcc``
> and
> ``g++`` to ``/usr/local/bin``, which is normally searched before
> ``/usr/bin``,
> so that every invokation of either of these commands goes through
> ``ccache``:
>
> ++ I don't like this implementation of CCache. I think this should be a
> CMake command-line option, not a system symbolic link.
> ++ Did you try the CMake solution? Did it not work?
>
> =-=-=-=-=-=-=-= Text:
> Setting Up a Buildbot Master
>
> ++ This is entirely optional (from a buldslave point of view) and would be
> good if you could point out that
> ++ I'd recommend to both write "(optional)" and write that this is only
> needed in the first time
>
> =-=-=-=-=-=-=-= Text:
>          'name': 'clang-armv7la15-linux',
>
> ++ For consistency, please use "clang-native-arm-cortex-a15" for simple
> "check-all" bots.
> ++ As we get more bots running, we might think of a better name for them,
> I agree the current ones aren't good. ;)
>
>
> =-=-=-=-=-=-=-= Text:
> Installing and Configuring a Buildbot Slave
>
> ++ We already have a document on that, would be good to point to it.
> ++ If that doc is not good enough, updating it would be prefered
>
>
> =-=-=-=-=-=-=-= Text:
> Now you mail off three things to `Galina Kistanova <mailto:
> gkistanova at gmail.com>`_:
>
> #. The patch of the changes you made to Zorg (``svn diff > zorg.patch``).
> #. The build slave's name (``mily-odroid-xu-1``).
> #. And the secret password to the slave.
>
> ++ Of the three things above, only the password should be emailed to
> Galina directly
> ++ The names can be inferred from your patch to Zorg
> ++ And the patch should be sent to Galina, copying llvm-commits (more
> formalism than practicality, but still...)
>
>
> =-=-=-=-=-=-=-= Text:
> Epilogue
>
> ++ We don't normally put emails on our documentation, nor state the author
> explicitly, since they're changed by too many people
> ++ We don't want you to receive emails about other people's changes 10
> years from now... ;)
> ++ Also, that diminishes the contribution of other folks to the docs,
> including changes and tips on the mailing list.
>
>
> cheers,
> --renato
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20131122/c1eee0bf/attachment.html>


More information about the llvm-commits mailing list