search for: insignifant

Óscar Fuentes <ofv at wanadoo.es> writes: > 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 insignifant. Oh, it's significant. When I build the Cray compiler with only non-LLVM stuff changed, the actual compiles (the Cray stuff) finish before the LLVM figures out nothing has changed. This is a sginificant productivity loss. The Cray compiler uses a non-recursive make and so gets tons of paral...

...<ofv at wanadoo.es> writes: > >> 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 insignifant. > > Oh, it's significant. When I build the Cray compiler with only non-LLVM > stuff changed, the actual compiles (the Cray stuff) finish before the > LLVM figures out nothing has changed. This is a sginificant > productivity loss. How is that? Your compiler builds in less tha...

...and found it to > be substantially faster than the recursive makefile. 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 insignifant. Furthermore, recursive make is necessary for automatic generation of header dependencies, among other things. The makefiles generated by cmake are "partially" recursive for that reason: http://www.cmake.org/Wiki/CMake_FAQ#Why_does_CMake_generate_recursive_Makefiles.3F >>> 2....

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 >

...s> writes: >> >>> 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 insignifant. >> >> Oh, it's significant.  When I build the Cray compiler with only non-LLVM >> stuff changed, the actual compiles (the Cray stuff) finish before the >> LLVM figures out nothing has changed.  This is a sginificant >> productivity loss. > > How is that? You...

...s> writes: >> >>> 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 insignifant. >> >> Oh, it's significant. When I build the Cray compiler with only non-LLVM >> stuff changed, the actual compiles (the Cray stuff) finish before the >> LLVM figures out nothing has changed. This is a sginificant >> productivity loss. > > How is that? You...

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.