search for: sublibrary

Óscar Fuentes <ofv at wanadoo.es> writes: > Chris Lattner <clattner at apple.com> writes: > >> There are different overheads in different scenarios. The makefiles >> get really poor utilization out of a 8 or 16-way machine because of >> implicit synchronization between different sublibraries. > > BTW, adding explicit library dependencies will make the

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

...s()), without getting any answer. Now I have updated all packages separately, and found that the problem comes from nlme: Everything comes home, the md5 checksums are ok, but then the old version can??t be removed from my computer, leaving a "nlme" library with only the "libs" sublibrary left. As my R doesn??t start without nlme, I am stuck here. R doesn??t start with only the "libs" left and doesn??t start without nlme. What??s going on? It??s no big crisis as I have the nlme version from the R installation file, but I try to keep my installation as updated as possible...

greened at obbligato.org (David A. Greene) writes: > Óscar Fuentes <ofv at wanadoo.es> writes: > >> Chris Lattner <clattner at apple.com> writes: >> >>> There are different overheads in different scenarios. The makefiles >>> get really poor utilization out of a 8 or 16-way machine because of >>> implicit synchronization between different

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

Hi ;-) Where can I find the "Vorbis API full documentation"? Functions description, return values, errors. Thanks for your time. Ulises10 Mendoza-Argentina

Hi! I'm porting my own projects to CMake (seems very cool) and I want to import LLVM as external libraries. To simplify this CMake supports an export feature that can export an LLVM.cmake file that lists all libraries of LLVM. With this I could simplify the use of LLVM in my own CMake project. For this the following cmake files of LLVM have to be extended (patches are provided at the end of

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

Óscar Fuentes <ofv at wanadoo.es> writes: >>>> There are different overheads in different scenarios. The makefiles >>>> get really poor utilization out of a 8 or 16-way machine because of >>>> implicit synchronization between different sublibraries. >>> >>> BTW, adding explicit library dependencies will make the parallel builds

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

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 >

Hi, everyone, As you may know, NVIDIA has developed an open-source Fortran frontend for LLVM (http://flang-compiler.org), which consists of the flang frontend itself along with the corresponding Fortran runtime library. The existing frontend's code is mostly written in C, and while a production-quality implementation, does not follow modern software-engineering practices. Our long-standing