building clang when present

This patch eases building clang when present in the source tree. Since clang is revlocked to llvm, one usually updates them together, and builds them together.

Ok?

clang-3.patch (794 Bytes)

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™ :wink:

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. :slight_smile:

Mike Stump <mrs@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. :slight_smile:

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" :slight_smile:

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.

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" :slight_smile:

Not my fault clang doesn't build when I type make. :slight_smile: 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. :slight_smile:

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.

:slight_smile: 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.

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™ :wink:

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 :slight_smile:

I'll add OPTIONAL_PARALLEL_DIRS, if people would rather it be done
that way. :slight_smile:

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 :slight_smile:

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.

llvm-clang.diff (955 Bytes)