NAKAMURA Takumi via llvm-dev
2017-Jul-20 15:31 UTC
[llvm-dev] FYI: Ninja-build user may use CMake-3.9
This is useful for developer who uses multicore builder. https://cmake.org/cmake/help/v3.9/release/3.9.html#other-changes - The Ninja <https://cmake.org/cmake/help/v3.9/generator/Ninja.html#generator:Ninja> generator has loosened the dependencies of object compilation. Object compilation now depends only on custom targets and custom commands associated with libraries on which the object’s target depends and no longer depends on the libraries themselves. Source files in dependent targets may now compile without waiting for their targets’ dependencies to link. With BUILD_SHARED_LIBS, compiling units don't wait for preceding shared libs. See also; http://bb.pgr.jp/builders/i686-mingw32-RA-on-linux Regardless of BUILD_SHARED_LIBS, compile units in add_executable() don't wait for preceding libraries, but targets by add_dependencies(). It doesn't break anything in llvm tree. Assume; add_executable(foo foo.cpp) target_link_libraries(foo LLVMCore) # depends on intrinsics_gen Compiling foo.cpp doesn't wait for LLVMCore, but intrinsics_gen. Linking foo waits for LLVMCore. I have been working for cutting dependencies to increase parallelism. For example, I introduced ENABLE_OBJLIB. See also, https://reviews.llvm.org/rL305635 Ninja with CMake-3.9 doesn't require parallelize with objlib. I love ninja-build. Thanks, Takumi -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170720/396f2f4d/attachment.html>
Reid Kleckner via llvm-dev
2017-Jul-20 16:16 UTC
[llvm-dev] FYI: Ninja-build user may use CMake-3.9
This is great news! Do we know who contributed the changes to cut the extra library dependencies? Do you think we should remove ENABLE_OBJLIB to simplify our CMake files in the near future? It seems to me that anyone who cares about highly parallel build throughput can upgrade CMake to get the good behavior. It's probably easier and less error-prone than maintaining a special build configuration. On Thu, Jul 20, 2017 at 8:31 AM, NAKAMURA Takumi via llvm-dev < llvm-dev at lists.llvm.org> wrote:> This is useful for developer who uses multicore builder. > https://cmake.org/cmake/help/v3.9/release/3.9.html#other-changes > > > - The Ninja > <https://cmake.org/cmake/help/v3.9/generator/Ninja.html#generator:Ninja> generator > has loosened the dependencies of object compilation. Object compilation now > depends only on custom targets and custom commands associated with > libraries on which the object’s target depends and no longer depends on the > libraries themselves. Source files in dependent targets may now compile > without waiting for their targets’ dependencies to link. > > With BUILD_SHARED_LIBS, compiling units don't wait for preceding shared > libs. > See also; http://bb.pgr.jp/builders/i686-mingw32-RA-on-linux > Regardless of BUILD_SHARED_LIBS, compile units in add_executable() don't > wait for preceding libraries, > but targets by add_dependencies(). > > It doesn't break anything in llvm tree. Assume; > add_executable(foo foo.cpp) > target_link_libraries(foo LLVMCore) # depends on intrinsics_gen > Compiling foo.cpp doesn't wait for LLVMCore, but intrinsics_gen. > Linking foo waits for LLVMCore. > > I have been working for cutting dependencies to increase parallelism. > For example, I introduced ENABLE_OBJLIB. > See also, https://reviews.llvm.org/rL305635 > Ninja with CMake-3.9 doesn't require parallelize with objlib. > > I love ninja-build. > > Thanks, > Takumi > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170720/992eecd4/attachment.html>
Martell Malone via llvm-dev
2017-Jul-20 16:32 UTC
[llvm-dev] FYI: Ninja-build user may use CMake-3.9
Hey Reid, I tracked down the relevant gitlab issue, merge request and commits on kitware. https://gitlab.kitware.com/cmake/cmake/issues/15555 https://gitlab.kitware.com/cmake/cmake/merge_requests/430 Ben from kitware seems to have done the heavy lifting here Best, Martell On Thu, Jul 20, 2017 at 5:16 PM, Reid Kleckner via llvm-dev < llvm-dev at lists.llvm.org> wrote:> This is great news! Do we know who contributed the changes to cut the > extra library dependencies? > > Do you think we should remove ENABLE_OBJLIB to simplify our CMake files in > the near future? It seems to me that anyone who cares about highly parallel > build throughput can upgrade CMake to get the good behavior. It's probably > easier and less error-prone than maintaining a special build configuration. > > On Thu, Jul 20, 2017 at 8:31 AM, NAKAMURA Takumi via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> This is useful for developer who uses multicore builder. >> https://cmake.org/cmake/help/v3.9/release/3.9.html#other-changes >> >> >> - The Ninja >> <https://cmake.org/cmake/help/v3.9/generator/Ninja.html#generator:Ninja> generator >> has loosened the dependencies of object compilation. Object compilation now >> depends only on custom targets and custom commands associated with >> libraries on which the object’s target depends and no longer depends on the >> libraries themselves. Source files in dependent targets may now compile >> without waiting for their targets’ dependencies to link. >> >> With BUILD_SHARED_LIBS, compiling units don't wait for preceding shared >> libs. >> See also; http://bb.pgr.jp/builders/i686-mingw32-RA-on-linux >> Regardless of BUILD_SHARED_LIBS, compile units in add_executable() don't >> wait for preceding libraries, >> but targets by add_dependencies(). >> >> It doesn't break anything in llvm tree. Assume; >> add_executable(foo foo.cpp) >> target_link_libraries(foo LLVMCore) # depends on intrinsics_gen >> Compiling foo.cpp doesn't wait for LLVMCore, but intrinsics_gen. >> Linking foo waits for LLVMCore. >> >> I have been working for cutting dependencies to increase parallelism. >> For example, I introduced ENABLE_OBJLIB. >> See also, https://reviews.llvm.org/rL305635 >> Ninja with CMake-3.9 doesn't require parallelize with objlib. >> >> I love ninja-build. >> >> Thanks, >> Takumi >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170720/bf7df7f8/attachment.html>
NAKAMURA Takumi via llvm-dev
2017-Jul-20 23:07 UTC
[llvm-dev] FYI: Ninja-build user may use CMake-3.9
On Fri, Jul 21, 2017 at 1:16 AM Reid Kleckner <rnk at google.com> wrote:> This is great news! Do we know who contributed the changes to cut the > extra library dependencies? > > Do you think we should remove ENABLE_OBJLIB to simplify our CMake files in > the near future? It seems to me that anyone who cares about highly parallel > build throughput can upgrade CMake to get the good behavior. It's probably > easier and less error-prone than maintaining a special build configuration. >At the moment, this facility (loose deps) is specific to Ninja generator. There are a couple of users of ENABLE_OBJLIB. - Tablegen (except for ninja). - LIBCLANG_BUILD_STATIC. It doesn't use LLVM_ENABLE_OBJLIB, but uses it internally. Thanks, Takumi> On Thu, Jul 20, 2017 at 8:31 AM, NAKAMURA Takumi via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> This is useful for developer who uses multicore builder. >> https://cmake.org/cmake/help/v3.9/release/3.9.html#other-changes >> >> >> - The Ninja >> <https://cmake.org/cmake/help/v3.9/generator/Ninja.html#generator:Ninja> generator >> has loosened the dependencies of object compilation. Object compilation now >> depends only on custom targets and custom commands associated with >> libraries on which the object’s target depends and no longer depends on the >> libraries themselves. Source files in dependent targets may now compile >> without waiting for their targets’ dependencies to link. >> >> With BUILD_SHARED_LIBS, compiling units don't wait for preceding shared >> libs. >> See also; http://bb.pgr.jp/builders/i686-mingw32-RA-on-linux >> Regardless of BUILD_SHARED_LIBS, compile units in add_executable() don't >> wait for preceding libraries, >> but targets by add_dependencies(). >> >> It doesn't break anything in llvm tree. Assume; >> add_executable(foo foo.cpp) >> target_link_libraries(foo LLVMCore) # depends on intrinsics_gen >> Compiling foo.cpp doesn't wait for LLVMCore, but intrinsics_gen. >> Linking foo waits for LLVMCore. >> >> I have been working for cutting dependencies to increase parallelism. >> For example, I introduced ENABLE_OBJLIB. >> See also, https://reviews.llvm.org/rL305635 >> Ninja with CMake-3.9 doesn't require parallelize with objlib. >> >> I love ninja-build. >> >> Thanks, >> Takumi >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170720/2dc3e74d/attachment.html>