On Jan 19, 2009, at 12:35 PM, Dan Villiom Podlaski Christiansen wrote:> On 19 Jan 2009, at 21:16, Mike Stump wrote: > >> On Jan 19, 2009, at 11:55 AM, Dan Villiom Podlaski Christiansen >> wrote: >>> In my humble opinion, using OPTIONAL_DIRS would be better and >>> cleaner. >>> It may require some changes to ‘Makefile.rules’ to work as >>> intended, though. If there's interest in such a change, I can >>> prepare >>> a patch? >> >> Are OPTIONAL_DIRS parallel? For some reason, I was assuming not. > > Well, from my recollection, PARALLEL_DIRS and the other *_DIRS don't > interact terribly well with each other with the current LLVM build > system. It may or may not actually be executed parallel with other > directories, but I wouldn't consider that a problem, as Clang itself > contains quite a lot of source files, libraries and directories. > Parallelism within the Clang source should be Good Enough™ ;)If there are bugs in the parallel aspects of llvm, I've never hit them. I only ever build 8-way, and I expect it to just work; if it doesn't, I'd rather just fix it. Avoiding parallel isn't the way to get a build system that just works in parallel. Lastly, I'm more demanding than, good enough. I'll add OPTIONAL_PARALLEL_DIRS, if people would rather it be done that way. :-)
Mike Stump <mrs at apple.com> writes:> If there are bugs in the parallel aspects of llvm, I've never hit > them. I only ever build 8-way, and I expect it to just work; if it > doesn't, I'd rather just fix it. Avoiding parallel isn't the way to > get a build system that just works in parallel. Lastly, I'm more > demanding than, good enough. > > I'll add OPTIONAL_PARALLEL_DIRS, if people would rather it be done > that way. :-)I see that a significant amount of work is devoted to enhancing/fixing the current build framework, which is perfectly okay with me, but seeing once and again how you guys work on the build instead of enhancing/fixing LLVM itself makes me think "what a waste of talent" :-) Adding CMake support for integrating clang into the LLVM build took me about 15 minutes. The only change to the pre-existing LLVM CMake specification was if( EXISTS ${CMAKE_CURRENT_SOURCE_DIR}/clang/CMakeLists.txt ) add_subdirectory( ${CMAKE_CURRENT_SOURCE_DIR}/clang ) endif() and just this gives a lot of benefit: parallel builds, multiplatform, multicompiler, robustness, etc. With some work it is possible to support building clang on an arbitrary directory, even putting LLVM as a subdirectory of clang, which is more natural than the current arrangement. This feature could be of benefit to those working on their own compiler too: integrating LLVM on a external CMake build spec would require three or four lines of code on the user's CMakeFiles.txt. I have a prototype that does this, but I'm waiting for some extra free time to polish it. The only serious non-trivial thing the current LLVM CMake specification lacks is "make check", and here I'm having some problems. First, because it is not posible (AFAIK) to completely mimic "make check" (make check itself is no problem, the options you can use are the tricky part, like requiring certain test case or set of test cases). Second, because I don't know what you would consider acceptable, as I have no personal experience nor criteria about executing test cases. Third, because the enhancements recently incorporated to the test framework (C++ unit tests). Fourth and final, because of a severe lack of time. Implementing the bells and whistles the cmake spec still lacks compared to configure & make seems an easy work to me. So if you are on the mood of devoting your time to enhancing the LLVM build system, please consider working on the CMake spec, and specifically on "make check" support. -- Oscar
On Jan 19, 2009, at 1:44 PM, Óscar Fuentes wrote:> I see that a significant amount of work is devoted to enhancing/fixing > the current build framework, which is perfectly okay with me, but > seeing > once and again how you guys work on the build instead of > enhancing/fixing LLVM itself makes me think "what a waste of > talent" :-)Not my fault clang doesn't build when I type make. :-) I don't consider adding 2 lines to be all that time consuming. As for what I work on, well, if someone else had it building before I got to it, I would not have had to do the work, therefore, it falls on me, if I want it to build. Not my choice, that's just how it worked out. :-)> With some work it is possible to support building clang on an > arbitrary directory, even putting LLVM as a subdirectory of clang, > which is more natural than the current arrangement.:-) Hey, I'd endorse that! I find that a more natural layout. Though, I don't want to do the work myself.> So if you are on the mood of devoting your time to enhancing the LLVM > build system, please consider working on the CMake spec, and > specifically on "make check" support.Presently that is outside the scope of what I'm working on.
Dan Villiom Podlaski Christiansen
2009-Jan-20 14:56 UTC
[LLVMdev] building clang when present
On 19 Jan 2009, at 21:53, Mike Stump wrote:> On Jan 19, 2009, at 12:35 PM, Dan Villiom Podlaski Christiansen wrote: >> On 19 Jan 2009, at 21:16, Mike Stump wrote: >> >>> On Jan 19, 2009, at 11:55 AM, Dan Villiom Podlaski Christiansen >>> wrote: >>>> In my humble opinion, using OPTIONAL_DIRS would be better and >>>> cleaner. >>>> It may require some changes to ‘Makefile.rules’ to work as >>>> intended, though. If there's interest in such a change, I can >>>> prepare >>>> a patch? >>> >>> Are OPTIONAL_DIRS parallel? For some reason, I was assuming not. >> >> Well, from my recollection, PARALLEL_DIRS and the other *_DIRS don't >> interact terribly well with each other with the current LLVM build >> system. It may or may not actually be executed parallel with other >> directories, but I wouldn't consider that a problem, as Clang itself >> contains quite a lot of source files, libraries and directories. >> Parallelism within the Clang source should be Good Enough™ ;) > > If there are bugs in the parallel aspects of llvm, I've never hit > them. I only ever build 8-way, and I expect it to just work; if it > doesn't, I'd rather just fix it. Avoiding parallel isn't the way to > get a build system that just works in parallel. Lastly, I'm more > demanding than, good enough.I don't believe any Makefile currently defines both PARALLEL_DIRS and one of the other DIRS variables. So you wouldn't have run into such bugs, yet :)> I'll add OPTIONAL_PARALLEL_DIRS, if people would rather it be done > that way. :-)My point is that the Clang source base is sufficiently large that there's little benefit to running it in parallel with other directories; parallelism within the Clang sources should more than suffice. I haven't tried compiling LLVM on any more than a dual core machine, so this is a bit theoretical for me :) Please try the attached patch and see if it suits your needs; it fixes OPTIONAL_DIRS so it works as intended for in-source builds too, and ensures that PARALLEL_DIRS are built *after* other targets; mainly for the purpose of consistency and reproducability. If ‘llvm-config’ were added to OPTIONAL_DIRS or DIRS, it would always be processed before the other directories. -- Dan Villiom Podlaski Christiansen, stud. scient., danchr at cs.au.dk, danchr at gmail.com -------------- next part -------------- A non-text attachment was scrubbed... Name: llvm-clang.diff Type: application/octet-stream Size: 955 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090120/0a0d5f19/attachment.obj> -------------- next part --------------