similar to: RFC: LLVM Build System Future Direction

> On Oct 24, 2019, at 02:17, Alex Denisov via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi Chris, > > This is a great initiative and it feels like the right direction. > > I'd like to add another point to the list: using LLVM as a library, i.e. being able to add it as a CMake subproject. > Currently it works pretty good, but some parts can be improved

Speaking on how to locate/enable projects (like clang/lldb) - even with the monorepo, I'm still enabling clang/lldb by symlinking them into llvm/tools, for one specific reason: CMake and relative paths. As long as all the source that is being built is below the toplevel CMake directory, and the build directory itself is within the toplevel CMake project directory, CMake uses relative

Sorry for the delay in writing this up and sending it out, but I wanted to recap the discussion from the roundtable on October 23rd. The roundtable ran for almost two hours and we discussed at most of the main points in my RFC. Thank you everyone who participated and contributed to the discussion! TL;DR: We should move to CMake 3.15 (RFC incoming). We should make `all` really `all`. We should

On Mon, Feb 8, 2016 at 12:45 PM, Hans Wennborg <hans at chromium.org> wrote: > Chris Bieneman is probably your best bet, and maybe also Dan Liew. > Hans, My current, and hopefully final, revision of the proposed patch is simplified and reworked to solve the problem entirely from cmake without touching the the llvm-build python scripts. Basically, the new fix for avoiding the

Hans, I have posted a complete patch for solving the linkage issues with LLVM_LINK_LLVM_DYLIB on Phabricator at http://reviews.llvm.org/D16945. The bulk of the fix the simple changes of... Index: cmake/modules/AddLLVM.cmake =================================================================== --- cmake/modules/AddLLVM.cmake (revision 259743) +++ cmake/modules/AddLLVM.cmake (working copy) @@

It seems to me that the feedback here has been generally positive, but a lot of different ideas have been added to the mix. To focus conversation and move things along I'm going to provide a summary of changes with proposals for rollout. Splitting Compiler-RT If we want to split compiler-rt, which I think makes a lot of sense, I think the best path forward is to copy the trunk (via svn cp).

Hi Simon, Please create a pull request here: https://github.com/xnorpx/opus/pulls Also please add a buildconfig here that exercise the BUILD_FRAMEWORK option: https://github.com/xnorpx/opus/blob/master/.github/workflows/build.yml [https://avatars2.githubusercontent.com/u/302709?s=400&v=4]<https://github.com/xnorpx/opus/blob/master/.github/workflows/build.yml>

>> >> >> cmake+ninja is a non-option for many developers. > > > By the way, i'm curious what this means. It can be interpreted in a > number of ways, but it would be good to know what problems you are > specifically saying making it a non-option for many developers Hi Danny, Sorry for being unclear. My fault for posting when I’m in a hurry. I don’t

----- Original Message ----- > From: "Jim Grosbach" <grosbach at apple.com> > To: "Daniel Berlin" <dberlin at dberlin.org> > Cc: llvmdev at cs.uiuc.edu > Sent: Wednesday, April 17, 2013 2:46:49 PM > Subject: Re: [LLVMdev] make check rebuilds the project? > > > > > > > > > > > cmake+ninja is a non-option for

On 11/14/2017, 01:26 AM, Chris Bieneman wrote: > Sorry for the delayed response. I've been out of town a lot lately. > > The documentation you referenced is unfortunately out of date (you might notice it still references autoconf). I'll see if I can find time to update it, but the guidance should be to use the `llvm_config` CMake function instead. The proper usage of that in the

On Wed, Apr 17, 2013 at 1:05 PM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- >> From: "Jim Grosbach" <grosbach at apple.com> >> To: "Daniel Berlin" <dberlin at dberlin.org> >> Cc: llvmdev at cs.uiuc.edu >> Sent: Wednesday, April 17, 2013 2:46:49 PM >> Subject: Re: [LLVMdev] make check rebuilds the

Hey Ben, Thank you for providing this feedback. I’m going to lay out some ideas that I have inline below. > On Jun 9, 2016, at 11:26 AM, Craig, Ben via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I'm great with moving the runtimes into their own directory and making cmake modules to standardize an interface between the LLVM build process and the runtime build process. I

At the LLVM Developer Meeting on October 23rd we held a CMake roundtable. One of the items we discussed was adopting a more regular timeline for CMake upgrades. During the roundtable there was overwhelming support for upgrading CMake, and support for treating CMake differently than how we treat upgrading host compilers. Historically we've taken into account recent versions of Visual Studio,

Any easy way to do this as some kind of overlay, so they GN files wouldn't live in the LLVM repository, but in a separate one? (this might avoid some of the community discussion - though would perhaps still likely have the issue I see as most significant: With a sufficient number of developers using GN, the rate of build breaks due to those developers missing CMake file updates might rise to

+1 to bumping cmake version and cleaning build system somewhat. On Tue, Oct 29, 2019 at 8:23 PM Tom Stellard via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 10/29/2019 10:10 AM, Chris Bieneman via llvm-dev wrote: > > At the LLVM Developer Meeting on October 23rd we held a CMake roundtable. One of the items we discussed was adopting a more regular timeline for CMake

On Tue, Oct 29, 2019 at 3:29 PM James Y Knight via llvm-dev < llvm-dev at lists.llvm.org> wrote: > CMake is extremely easy for developers to download and build locally -- or > just download binaries for if you like, too. > Is there any script we can/would provide to help with this? Or is it so simple that two lines in the "getting started" instructions would be enough?

Hi, In SUSE we have recently switched from building LLVM as multiple shared libraries (using BUILD_SHARED_LIBS) to building it as a single shared library (using LLVM_BUILD_LLVM_DYLIB). The multiple shared libraries build was causing issues and apparently it is only meant for LLVM developers. Our guidelines prohibit linking against static libraries unless there is no other option. After this

On Tue, Oct 29, 2019 at 8:40 PM David Blaikie <dblaikie at gmail.com> wrote: > > > > On Tue, Oct 29, 2019 at 10:28 AM Roman Lebedev via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> +1 to bumping cmake version and cleaning build system somewhat. >> >> On Tue, Oct 29, 2019 at 8:23 PM Tom Stellard via llvm-dev >> <llvm-dev at

Actually forward to LLVM-dev because I obviously don’t know how email works… -Chris > Begin forwarded message: > > From: Chris Bieneman via cfe-dev <cfe-dev at lists.llvm.org> > Subject: [cfe-dev] Raising CMake minimum version to 3.4.3 > Date: April 26, 2016 at 3:01:23 PM PDT > To: cfe-dev <cfe-dev at lists.llvm.org>, llvm-dev at lists.apple.com > Cc: Galina

On Tue, Oct 29, 2019 at 12:48 PM Jean-Daniel via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > Le 29 oct. 2019 à 19:00, Roman Lebedev via llvm-dev < > llvm-dev at lists.llvm.org> a écrit : > > On Tue, Oct 29, 2019 at 8:40 PM David Blaikie <dblaikie at gmail.com> wrote: > > > > > On Tue, Oct 29, 2019 at 10:28 AM Roman Lebedev via llvm-dev