similar to: [LLVMdev] RFC: Upcoming Build System Changes

I have a very high level comment, and you may be able to directly shed light on it before I dig into a lot more detail. Why not simply standardize on CMake? It's not my favorite tool, but it seems to work well, we have established usage of it, and several people involved in the project who understand how it works. It doesn't seem like a significantly more burdensome dependency than Python

+1 We build our OpenCL SDK (for windows and Linux) using CMake. We’ve integrated LLVM’s Cmake hierarchy into our own (customizing LLVM external parameters like build and install directories, added passes, etc) Migrating LLVM’s build system from CMake to something else would require us to change the way we currently do things. From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at

Daniel Dunbar <daniel at zuster.org> writes: > I'm going to briefly summarize my responses here. > > On Fri, Oct 28, 2011 at 9:56 AM, Chris Lattner <clattner at apple.com> wrote: >> On Oct 28, 2011, at 12:54 AM, Óscar Fuentes wrote: >>> Anyways, if you wish to avoid duplicating info on both Makefile and >>> CMakeLists.txt there is a simple

On Oct 27, 2011, at 6:34 PM, Chandler Carruth wrote: > I have a very high level comment, and you may be able to directly shed light on it before I dig into a lot more detail. > > Why not simply standardize on CMake? It's not my favorite tool, but it seems to work well, we have established usage of it, and several people involved in the project who understand how it works. It

On Oct 28, 2011, at 12:54 AM, Óscar Fuentes wrote: > A good measure of how fast a set of Makefile are is to run the build > with all targets up-to-date. Both builds takes a few seconds (3 or so) > on my Linux quad core box. Whatever improvement can be achieved on this > seems pretty insignificant. There are different overheads in different scenarios. The makefiles get really poor

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) @@

Hi all, I'm new to Clang and LLVM and I'd like to use them on Win 8 with Code::Blocks. I'm having problems in running cmake. I did the following: * Installed cmake * installed Code::Blocks * Installed python (cmake was complaining if it was not installed) * Dowloaded sources fron svn (LLVM, clang, compilre-rt and test-suite. When I run cmake I got The following error:

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

Daniel, I'm just a 42 year old former NeXT and Apple Dev who back in Mechanical Engineering is excited about OpenCL/OpenGL and all that is with LLVM/Clang, but I've got to say that even though my plans include learning Python for various areas of development the last I want to deal with is a Build system needing it to compile a Compiler Suite. Autotools is a bag of hurt, always has

On Fri, Oct 28, 2011 at 1:31 PM, Óscar Fuentes <ofv at wanadoo.es> wrote: > Daniel Dunbar <daniel at zuster.org> writes: > >> I'm going to briefly summarize my responses here. >> >> On Fri, Oct 28, 2011 at 9:56 AM, Chris Lattner <clattner at apple.com> wrote: >>> On Oct 28, 2011, at 12:54 AM, Óscar Fuentes wrote: >>>> Anyways, if

Chris Lattner <clattner at apple.com> writes: > On Oct 28, 2011, at 12:54 AM, Óscar Fuentes wrote: >> A good measure of how fast a set of Makefile are is to run the build >> with all targets up-to-date. Both builds takes a few seconds (3 or so) >> on my Linux quad core box. Whatever improvement can be achieved on this >> seems pretty insignificant. > > There

I'm going to briefly summarize my responses here. On Fri, Oct 28, 2011 at 9:56 AM, Chris Lattner <clattner at apple.com> wrote: > On Oct 28, 2011, at 12:54 AM, Óscar Fuentes wrote: >> Anyways, if you wish to avoid duplicating info on both Makefile and >> CMakeLists.txt there is a simple solution: read and parse the Makefile >> from the corresponding CMakeLists.txt.

Hi all, *TL;DR:* I have a target TMS9900CodeGen but cmake is looking for LLVMTMS9900 or LLVMTMS9900CodeGen which I don't have, and cmake dies. But the MSP430 target doesn't have that either, and cmake is happy with it. What am I missing? *The premise:* I may be making a huge mistake, but I'm trying to develop an LLVM backend. I'm writing up some notes while I do so, and I hope

Giorgio Franceschetti <g.franceschetti at vidya.it> writes: > When I run cmake I got The following error: > *<project folder>\build>CMake -G "CodeBlocks - MinGW Makefiles" ..\llvm* > /-- Could NOT find LibXml2 (missing: LIBXML2_LIBRARIES > LIBXML2_INCLUDE_DIR)// > //-- Target triple: x86_64-w64-mingw32// > //-- Native target architecture is X86// >

Hi Folks, Although LLVM now relies on cmake for its build configuration, it still calls an external Python script, namely llvm-build, to manage component dependecies, activation or deactivation of target componenents and generating description for llvm-config. This system is documented in http://llvm.org/docs/CommandGuide/llvm-build.html and https://llvm.org/docs/LLVMBuild.html. Several

[Repost: The mailing list was down yesterday. Sorry if this is a duplicate] I'm evaluating CMake (1) primarily as an alternative build system for Visual Studio users, although it can easily be a replacement for `configure' and hand-made makefiles too, providing a single build system for all platforms. CMake is a tool that takes a project description and configures, generates makefiles,

Am Fr., 5. Juli 2019 um 07:01 Uhr schrieb Joerg Sonnenberger via llvm-dev <llvm-dev at lists.llvm.org>: > > On Fri, Jul 05, 2019 at 10:43:12AM +0000, Simon Tatham via llvm-dev wrote: > > But before I do that, I wanted to check whether there would be any > > objection on grounds of build dependencies. Is it acceptable to require Python > > as part of the normal build

On Thu, 11 Jul 2019 at 21:44, Joerg Sonnenberger via llvm-dev <llvm-dev at lists.llvm.org> wrote: > That's what I said. The cmake based build system needs it. LIT is > optional. It is entirely feasible to have a custom build system and no > Python at all. It would be quite painful to break that. To be explicit (and correct me if I misstate facts), NetBSD wants to build Clang

Hi, On 2016-12-29 13:17:50 -0800, Philip Reames wrote: > Having something like this available in tree would definitely be > useful. Cool. > For simplicity, why don't we start with support for the second style? This > is the long term useful one and would be a good starting point for getting > the code in tree. Works for me. > Can you give a pointer to the patch so that

Having something like this available in tree would definitely be useful. For simplicity, why don't we start with support for the second style? This is the long term useful one and would be a good starting point for getting the code in tree. Can you give a pointer to the patch so that I can assess the rough complexity? If it's simple enough, I'd be happy to help get it reviewed