similar to: [cfe-dev] GN build roundtable summary; adding GN build files to the repo

If I read this correctly, there isn't much opposition to landing the gn files as long as it's very clear that regular devs aren't supposed to update them and that it's clear that they're experimental The main concerns I've heard so far: - Having two build systems is confusing. I can see this, but I think putting the gn files below llvm/experimental/gn (instead of right

The value in having them somewhere in-tree is that it's easier for people collaborate on these files, and it's way lower setup overhead if someone wants to try it out. If people prefer llvm/util over llvm/experimental, that's fine with me. There would only be a single directory that will contain build files for all of llvm, clang, lld, etc. The build files would be in

Awesome. I'm happy with moving the .rst file into that directory and not have it on the public website. I'll try to make a patch that lands enough scaffolding to build `not` in the next few days, and then I'll land the other build files I have through the regular build process after that. Unless someone feels strongly, I'll go with Justin's suggestion of llvm/utils/gn/... On

On Thu, Nov 1, 2018 at 1:22 AM Vedant Kumar via cfe-dev <cfe-dev at lists.llvm.org> wrote: > > Hi all, > >> On Oct 31, 2018, at 11:18 AM, Nico Weber via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Hi, >> >> first things first: If you're happy with cmake, you can stop reading now. >> I'm not, I just put up with it :) > ...

vitalybuka, sanitizer-x86_64-linux-gn is _still_ on http://lab.llvm.org:8011/console . Can we please get it removed? On Wed, Jul 3, 2019 at 7:07 AM Nico Weber <thakis at chromium.org> wrote: > https://reviews.llvm.org/D63909 landed. Maybe it needs a master restart > to have an effect? > > On Wed, Jul 3, 2019 at 1:03 PM Roman Lebedev <lebedev.ri at gmail.com> wrote: >

Why does GN bot still send mails? I thought it got fixed? On Wed, Jul 3, 2019 at 1:44 PM <llvm.buildmaster at lab.llvm.org> wrote: > > The Buildbot has detected a new failure on builder sanitizer-x86_64-linux-gn while building llvm. > Full details are available at: > http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-gn/builds/1820 > > Buildbot URL:

On Wed, Jul 31, 2019 at 11:37 AM Vitaly Buka via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I have no idea how. > Are there particular problems? Now it should be quite. > Console has a bunch of stale builders which are even less useful. > LLVM has a silent build master that does not send email. When Nico added the gn build, apparently we promised not to set up builders

Why is there a public GN buildbot that sends emails and IRC notifications? That isn't what was agreed upon. Either un-GM it, or silence it. Roman. On Fri, Jun 28, 2019 at 1:05 AM <llvm.buildmaster at lab.llvm.org> wrote: > > The Buildbot has detected a new failure on builder sanitizer-x86_64-linux-gn while building llvm. > Full details are available at: >

Hello, I was wondering who owns the clang.exp bots which builds llvm using gn? I need to add another generator to clang-tablegen, but the build seems to be failing: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-gn/builds/4816 I'd appreciate it if someone could take a look at the problem. Thank you, Nandor Licker

On Tue, Sep 1, 2020 at 3:57 PM David Blaikie <dblaikie at gmail.com> wrote: > > > On Tue, Sep 1, 2020 at 12:42 PM Nico Weber <thakis at chromium.org> wrote: > >> On Tue, Sep 1, 2020 at 3:32 PM David Blaikie <dblaikie at gmail.com> wrote: >> >>> On Tue, Sep 1, 2020 at 12:07 PM Nico Weber via cfe-dev < >>> cfe-dev at lists.llvm.org>

Hi Wynand, My big concern is related to what Mehdi mentioned as #4. Bazel doesn't really handle the configuration-management that CMake does, so adding Bazel support would really mean supporting an extra build system with no path for it to replace CMake. We're kinda already in that situation with gn, but gn is a developer productivity tool and we don't consider changes that break gn

I previously <https://groups.google.com/g/llvm-dev/c/u07o3QREVUg/> proposed contributing Bazel build files to the LLVM monorepo, supported *only* by interested community members and not to interfere with or affect the existing CMake configuration. As part of that conversation, it became clear that the LLVM policies for more "peripheral" components were not clearly documented. We

On Tue, Sep 1, 2020 at 3:32 PM David Blaikie <dblaikie at gmail.com> wrote: > On Tue, Sep 1, 2020 at 12:07 PM Nico Weber via cfe-dev < > cfe-dev at lists.llvm.org> wrote: > >> Hi, >> >> llvmbb's job is to inform people of build breaks. However, it seems to >> trigger for a big list of bots, and at least one of them seems to always be >>

On Fri, Jan 11, 2019 at 11:18 AM Davide Italiano via llvm-dev < llvm-dev at lists.llvm.org> wrote: > After yet another round of discussions, the plan is that of trying not > to slap another attribute on the members, instead going for making > OPTIMIZED_TLBGEN the default and removing always_inline. > I'll do some testing locally (for the Ninja and the Xcode build >

Hi, many of the bots on http://lab.llvm.org:8011/console don't do anything in their compile phase, even if they should. For example, these bots all don't do anything in their compile phase in any builds, even if they should: http://lab.llvm.org:8011/builders/clang-x64-ninja-win7/ http://lab.llvm.org:8011/builders/clang-ppc64be-linux

Hi Nico, Hans, Takumi, I made it to the bottom of the issue. Turns out that CMAKE_C_FLAGS=-m64 CMAKE_CXX_FLAGS=-m64 CMAKE_EXE_LINKER_FLAGS=/machine:x64 is enough to do a 64-bit build correctly with a 32-bit clang-cl (i.e. one that targets 32-bit by default). Hooray! The missing piece that I had to track down is why I would see `deps = msvc` stuff spewing onto my terminal, rather than consumed

Dear people, I'm trying to do some analysis of a data using the models by Royle & Donazio in their fantastic book, particular the following function: http://www.mbr-pwrc.usgs.gov/pubanalysis/roylebook/panel4pt1.fn that applied to my data and in the console is as follows: > `desman.y` <- structure(c(3L,4L,3L,2L,1L), .Names = c("1", "2", "3",

On Wed, Jun 5, 2019 at 1:33 PM <vsk at apple.com> wrote: > > > On Jun 4, 2019, at 4:41 PM, Nico Weber <thakis at chromium.org> wrote: > > On Mon, Jun 3, 2019 at 2:06 PM <vsk at apple.com> wrote: > >> Hi Nico, >> >> Sorry for the delay, I've been OOO. The llvm-cov bot should produce >> reports for llvm-undname starting today. >>

Hi, It seems the problem is that the bot is updating llvm.src, but trying to build from llvm. Galina, it looks like this is related to your recent changes to zorg, you probably missed a spot somewhere and I can't find it on a first glance. Could you have a look? Thanks, Diana On 5 September 2016 at 12:01, Diana Picus <diana.picus at linaro.org> wrote: > Hi Nico, > > Thanks

Thanks for the info Rui. Transitioning from llvm 5.0 to llvm 7.0 will take some time due to the nature/process of the production environment. Is it ok to use lld 7.0 with llvm 5.0? On Thu, Jun 13, 2019 at 1:47 PM Rui Ueyama <ruiu at google.com> wrote: > Looks like Ubuntu 12 was released in 2012, and the most recent version of > LLVM is LLVM 8.0.0. > > LLVM 5.0 is pretty old,