search for: sublibraries

...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 parallel builds > worse, No they won't, for exactly the reason Chris stated. > because you know when a dependency is missing (the build fails) > but you don't know when a dependency is superfluous. That's tr...

...ux 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 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 worse, because you know when a dependency is missing (the build fails) but you don't know when a dependency is superfluous. >> Furthermore, recursive make is necessary for automatic generation of >> header de...

Hello all, R2.2.1, W2k I posted a similar question last week after having problem with a group update (using update.packages()), 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

...ites: > >> 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 parallel builds >> worse, > > No they won't, for exactly the reason Chris stated. That's makes no sense. The automatic system we had generated an optimal dependency graph: no missing or unnecesary edges...

...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 utilization out of a 8 or 16-way machine because of implicit synchronization between different sublibraries. > 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_Makef...

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

...,7 @@ add_dependencies( ${name} ${LLVM_COMMON_DEPENDS} ) endif( LLVM_COMMON_DEPENDS ) install(TARGETS ${name} + EXPORT LLVM LIBRARY DESTINATION lib${LLVM_LIBDIR_SUFFIX} ARCHIVE DESTINATION lib${LLVM_LIBDIR_SUFFIX}) # The LLVM Target library shall be built before its sublibraries Index: CMakeLists.txt =================================================================== --- CMakeLists.txt (revision 104943) +++ CMakeLists.txt (working copy) @@ -394,4 +394,7 @@ PATTERN ".svn" EXCLUDE ) +# install LLVM package +install(EXPORT LLVM DESTINATION cmake) +...

...atever improvement can be achieved on this >>> seems pretty insignificant. >> >> 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 > worse, because you know when a dependency is missing (the build fails) > but you don't know when a dependency is superfluous. > >>> Furthermore, recursive make is necessary for automatic gener...

Ó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 >>> worse, >> >> No they won't, for exactly the reason Chris stated. > > That's makes no sense. The automatic system we had generated an optimal > dependency gra...

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