similar to: [LLVMdev] [cfe-dev] RFC: Upcoming Build System Changes

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

+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, 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

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

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

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

Chris Lattner <clattner at apple.com> writes: >>> 1. It generates really slow build systems. >> >> In my Linux box, last time I checked (long time ago) the cmake build was >> a bit faster than the Makefiles. But this is a tricky terrain, because >> they are not identical, not on the features supported (and some have an >> impact on build-time) nor

Hi all, As you might have inferred, I'm in the process of working on some changes to the way LLVM builds. I have outlined a rough proposal below, unless there are any major objections I will probably start committing stuff next week. This message may be verbose, if you want the executive summary, skip to 'What This Means For Jane "LLVM Developer" Doe' at the bottom.

On Fri, Oct 28, 2011 at 3:54 AM, Óscar Fuentes <ofv at wanadoo.es> 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. For instance, if you put the > library dependencies on the Makefile like this: > > LLVMLIBDEPS := foo zoo bar >

On Fri, Oct 28, 2011 at 12:43 PM, Óscar Fuentes <ofv at wanadoo.es> wrote: > 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

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

On Wed, Nov 02, 2011 at 12:29:33AM +0100, Óscar Fuentes wrote: > Joerg Sonnenberger > <joerg at britannica.bec.de> writes: > > > So I am maintaing Makefiles for NetBSD for LLVM as well. I know the > > FreeBSD guys do the same for them. > > Maybe it is not useful for the FreeBSD guys, but the makefiles generated > by cmake are compatible with BSD `make'

Hi, On 2017-02-01 23:20:40 -0800, Andres Freund wrote: > > 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 and in. If it's more complicated, I probably won't have the > > time to assist. > > Patch (and a prerequisite) attached. Took me a while to get

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.

I've been experimenting with building various llvm variants on mac OS X. Ususally, it's a case of cloning, running cmake with Xcode as generator and loading the resulting xcodeproj. In trying to build the skeleton openrisc backend from https://github.com/asl/llvm-openrisc as described in "building a backend in 24 hours" at

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

On Oct 27, 2011, at 11:28 PM, Óscar Fuentes wrote: > Chris Lattner <clattner at apple.com> writes: > >> There are several major problems with CMake IMO: >> >> 1. It generates really slow build systems. > > In my Linux box, last time I checked (long time ago) the cmake build was > a bit faster than the Makefiles. But this is a tricky terrain, because >

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

Nico Weber <thakis at chromium.org> writes: > On Tue, Nov 1, 2011 at 3:09 PM, David A. Greene <greened at obbligato.org> wrote: >> Óscar Fuentes <ofv at wanadoo.es> writes: >> >>> Okay, we can get rid of recursive make. However, as pointed out >>> elsewhere, removing recursive make will not make a difference on the >>> LLVM build. What

Hi, I've been working on a set of patches to statically link polly in the LLVM tools. There remains an error I can't seem to solve when linking llvm-lto (all other tools luckily get linked correctly): it insists adding libLLVMipo.a after libLLVMPolly.a on the link command, resulting in an error of the form: PassManagerBuilder.cpp:(.text+0x499): undefined reference to