search for: llvmlab

...of the selections, like "console" for example, do not work when I click on them. On 03/27/2013 03:57 PM, Michael Gottesman wrote: > Hello LLVM Dev and Clang Dev! > > David Dean and I just finished bringing up a new build master on > lab.llvm.org <http://lab.llvm.org/>, llvmlab, which is located at the > url http://lab.llvm.org:8013 <http://lab.llvm.org:8013/> and is in #llvm > under the username llvmlab. > > llvmlab is different than the current buildbot based continuous > integration systems llvm uses; llvmlab is a phased builder based system. >...

Hello LLVM Dev and Clang Dev! David Dean and I just finished bringing up a new build master on lab.llvm.org, llvmlab, which is located at the url http://lab.llvm.org:8013 and is in #llvm under the username llvmlab. llvmlab is different than the current buildbot based continuous integration systems llvm uses; llvmlab is a phased builder based system. The high level details of the phased builder system are as foll...

...avorite internal tools: llvm bisect! First: I want to thank Daniel Dunbar for writing all the code for this tool, and Google for providing cloud storage and bandwidth to host it! We keep the compilers we build in the Green Dragon CI cluster, and now upload them to the Google Storage Cloud. The llvmlab bisect tool, takes those compilers and allows you to quickly bisect on a predicate. Instead of compiling those compilers again, the tool downloads them from the cloud. The tool allows you to down download and run compilers, or bisect on a range of commits with a predicate. Example, find where a...

Cool! This is great news. I feel like this information should be in our documentation somewhere. Could you start a new file ContinuousIntegration.rst and use this content to seed it? This new page would also be a good place to mention some LLVM idiosyncrasies like smooshlab being Apple-internal but still reporting via IRC; these things have not had a good place to be put yet. AFAIK currently our

On Wed, Mar 27, 2013 at 10:09:59PM -0700, Michael Gottesman wrote: > Incremental builds are quicker but less robust than clean builds. Can you do add clean-after-error behavior? I.e. default to incremental build, but do a clean rebuild after a failing build? Joerg

(I said the same thing in my last email = p, except a bit more conservative: do a clean build after 3 failures or something along those lines). Michael On Mar 28, 2013, at 6:16 AM, Joerg Sonnenberger <joerg at britannica.bec.de> wrote: > On Wed, Mar 27, 2013 at 10:09:59PM -0700, Michael Gottesman wrote: >> Incremental builds are quicker but less robust than clean builds. >

On Wed, Mar 27, 2013 at 3:57 PM, Michael Gottesman <mgottesman at apple.com>wrote: > 3. Later phases do broader, longer lasting testing than earlier phases. > Thus the 4 phases we currently have are: > > a. Phase 1 (sanity): Phase 1 is a quick non-bootstrapped, non-lto > compiler build, to check the ``basic sanity'' of the code base and build > process.

...ation This can be addressed once we fix the other issues. * Builders There are lots of python modules in ``zorg/zorg/buildbot/builders``. These are Factories, not builders so why do they have ``Builder`` in their name and are in the "builders" folder? This is unnecessarily confusing. * llvmlab, osuosl, smooshlab? Not sure those names are particularly helpful. I suspect ``smooshlab`` will probably be removed entirely and I suspect osuosl ought to be renamed. I'm not sure if we need to keep any of the llvmlab stuff. This is probably an incomplete list of issues but theses are issues...

On Mar 27, 2013, at 6:41 PM, Chandler Carruth <chandlerc at google.com> wrote: > > On Wed, Mar 27, 2013 at 3:57 PM, Michael Gottesman <mgottesman at apple.com> wrote: > 3. Later phases do broader, longer lasting testing than earlier phases. Thus the 4 phases we currently have are: > > a. Phase 1 (sanity): Phase 1 is a quick non-bootstrapped, non-lto

...ifferent story. As far as I know, we work with any recent version of slaves. Bounding the "dev/test setup" to any specific version could be easily avoided by choosing a right builder. So, this should not be a problem for someone who would wont to develop and test a build factory. > * llvmlab, osuosl, smooshlab? Reorganizing this currently is a work in progress. osuosl is in use; llvmlab is in use but will be decommissioned; smooshlab is used internally and is pending to be removed. In general, if you don't feel comfortable developing and debugging a build factory for the buildbot...

Hello everyone, LLVM buildmaster is up and running as lab.llvm.org:8011. Daniel Berlin is working on getting the current buildslave passwords from the old buildmaster, but this may not be possible. I'd suggest changing buildslave passwords anyway, just in case. Buildslave owners, please contact me directly with your new passwords and I'll update the master as soon as I can. Thanks

...me directly with your new passwords > and I'll update the master as soon as I can. should build slaves now use the osuosl configuration? For example osuosl/Config.py has def getBuildmasterHost(): return 'google1.osuosl.org' which is surely wrong now. On the other hand llvmlab doesn't have a base slave configuration file. Ciao, Duncan.

...g SVN (because git > bisect is more powerful, allows me to track all modules' history, and > will rid me of a complicated downstream set of SVN-bisect scripts). > > The only thing we *have* to have a sequential number for, are > releases. Even that can be ran manually. LNT and ‘llvmlab bisect’ also currently rely heavily on having sequential numbers as commit identifiers. Fred > We agreed to have sequential numbering from the start to allow > infrastructure to migrate slowly to a Git model. That can also have an > extra step to run the script if IDs are not populated...

> On Jul 5, 2016, at 3:44 AM, Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Quick re-cap. > > After a few rounds, not only the "external server" proposal got > obliterated as totally unnecessary, but the idea that we may even need > a hook at all is now challenged. This is not clear to me. How is the umbrella repository updated? —

On 30 June 2016 at 05:14, Tim Northover <t.p.northover at gmail.com> wrote: >> That makes it fragile, and that’s why I disagree with your “90% done” assessment. >> What if the service behing the hook is down for a few days? > > In the long-term view, a pretty trivial catch-up script ought to be > able to synthesize a sane history after any amount of down-time. >

On 08/26/2015 09:46 AM, Philip Reames wrote: > On 08/26/2015 09:41 AM, David Blaikie via llvm-dev wrote: >> >> >> On Wed, Aug 26, 2015 at 9:41 AM, Renato Golin >> <renato.golin at linaro.org <mailto:renato.golin at linaro.org>> wrote: >> >> On 26 August 2015 at 17:39, David Blaikie <dblaikie at gmail.com >> <mailto:dblaikie at

...do not force people to use a "git-only" solution.” (It seems that github has a SVN R/W access) http://lists.llvm.org/pipermail/llvm-dev/2016-May/100318.html - Joerg Sonnenberger: does not like git and prefer mercurial, didn’t find an email with a rational though. - Chris Matthews: LNT / llvmlab-bisect needs currently a sequential ID number http://lists.llvm.org/pipermail/cfe-dev/2016-July/049886.html - Mehmet Erol Sanliturk: "I consider revision numbers as only a disastrous design” http://lists.llvm.org/pipermail/llvm-dev/2016-May/100329.html <http://lists.llvm.org/pipermail/llvm-...

...e a "git-only" solution.” > (It seems that github has a SVN R/W access) > http://lists.llvm.org/pipermail/llvm-dev/2016-May/100318.html > - Joerg Sonnenberger: does not like git and prefer mercurial, didn’t find > an email with a rational though. > - Chris Matthews: LNT / llvmlab-bisect needs currently a sequential ID > number http://lists.llvm.org/pipermail/cfe-dev/2016-July/049886.html > - Mehmet Erol Sanliturk: "I consider revision numbers as only a disastrous > design” http://lists.llvm.org/pipermail/llvm-dev/2016-May/100329.html (+some > criticism of t...

Hi Justin, Firstly I really appreciate you taking the mantle and pushing this forward! Like Justin B I'll be bowing out after this. I thought it important because I don't believe you'll build consensus in this thread. I think the best that can be hoped for is opposition to give up fighting; advantages are to be had on both sides by different types of user and we've seen that many

Hi all, Now, four backends (if I am counting right: X86, ARM, AArch64, AMDGPU) are working on bringing-up GlobalISel, I’d like to switch the default of the LLVM_BUILD_GLOBAL_ISEL variable in CMake, such that the framework gets built by default. ** Impact of Flipping the Switch ** * Upsides * For people developing on GlobalISel, it will: - Simplify the CMake command to type :) - Build/Test