search for: rmch

...nto things that must be organized and coordinated; minute-long rebuilds still disrupt workflow. Time and effort spent on getting the build process fast are well invested. On the reasons why make-based builds are slow, Peter Miller has some insight to offer: http://miller.emu.id.au/pmiller/books/rmch/ . I'm not sure how widely recognized that paper is. Maybe it's widely known and today's build times stem from other things than recursive make. Regards, Jo

Joachim Durchholz <jo at durchholz.org> writes: > On the reasons why make-based builds are slow, Peter Miller has some > insight to offer: > http://miller.emu.id.au/pmiller/books/rmch/ . > I'm not sure how widely recognized that paper is. Maybe it's widely > known and today's build times stem from other things than recursive make. The paper is widely recognized. Its lessons, unfortunatly, are not. Chris is absolutely on-target as to why the current build is...

...> CMake just requires one plain text file named CMakeLists.txt on every > source directory, and the only maintenance is to keep up to date the > list of source files of the directory. Has anyone read "Recursive Make Considered Harmful"? http://miller.emu.id.au/pmiller/books/rmch/ http://aegis.sourceforge.net/auug97.pdf I have been using single top level Makefiles (and automake Makefile.am) for some time. For me they are far more reliable and maintainable. I have not yet tried CMake. For a large project using a single top level Makefile see the Linux kernel sources....

On Tue, Nov 01, 2011 at 11:09:41AM +0100, Joachim Durchholz wrote: > On the reasons why make-based builds are slow, Peter Miller has some > insight to offer: > http://miller.emu.id.au/pmiller/books/rmch/ . > I'm not sure how widely recognized that paper is. Maybe it's widely > known and today's build times stem from other things than recursive make. Please stop pointing to that article. It should be called "GNU make considered harmful" if anything, since most of the c...

greened at obbligato.org (David A. Greene) writes: > Joachim Durchholz <jo at durchholz.org> writes: > >> On the reasons why make-based builds are slow, Peter Miller has some >> insight to offer: >> http://miller.emu.id.au/pmiller/books/rmch/ . >> I'm not sure how widely recognized that paper is. Maybe it's widely >> known and today's build times stem from other things than recursive make. > > The paper is widely recognized. Its lessons, unfortunatly, are not. > > Chris is absolutely on-target as t...

...> greened at obbligato.org (David A. Greene) writes: > >> Joachim Durchholz <jo at durchholz.org> writes: >> >>> On the reasons why make-based builds are slow, Peter Miller has some >>> insight to offer: >>> http://miller.emu.id.au/pmiller/books/rmch/ . >>> I'm not sure how widely recognized that paper is. Maybe it's widely >>> known and today's build times stem from other things than recursive make. >> >> The paper is widely recognized. Its lessons, unfortunatly, are not. >> >> Chris is...

Am 01.11.2011 18:04, schrieb Joerg Sonnenberger: > On Tue, Nov 01, 2011 at 11:09:41AM +0100, Joachim Durchholz wrote: >> On the reasons why make-based builds are slow, Peter Miller has some >> insight to offer: >> http://miller.emu.id.au/pmiller/books/rmch/ . >> I'm not sure how widely recognized that paper is. Maybe it's widely >> known and today's build times stem from other things than recursive make. > > Please stop pointing to that article. It should be called "GNU make > considered harmful" if anything...

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

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

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.