[PATCH] D12679: [CMake] Flag recursive cmake invocations for cross-compile

Joseph Tremoulet via llvm-commits llvm-commits at lists.llvm.org
Tue Sep 8 12:09:28 PDT 2015


JosephTremoulet added a comment.

> I'm not familiar with the LLILC build system, can you explain how the required variable works?


Sure, happy to.

In brief: it tells us where to find a CoreCLR enlistment since we share some source files with them.

In long:
LLILC depends not only on LLVM, but also on the CoreCLR, and in some sense it's logically a sub-project of each.  So right off the bat it's an interesting question which of those source trees it makes sense to nest under each other.  We've settled on supporting both a configuration where LLILC lives in llvm/tools/llilc (with CoreCLR off somewhere else), and a configuration where all three trees are independent.  In either of those locations, there's no sensible default location to put/find the CoreCLR.
A point which I just glossed over but which may be interesting is that we're actually looking for the *output* of a CoreCLR build.  We're looking for source files in it, but as part of the build the relevant source files get copied over next to the output so that clients like us can pick them up (and eventually so that we can avoid having to build the CoreCLR locally and can just install a package with these sources and its binaries).
I believe a common pattern in cmake is to look for required binaries on the path (if no explicit location is given).  While the source files we're looking for here aren't binaries, they are next to some binaries, so we could require those binaries be on the path to build LLILC and avoid touching these LLVM files that way.  But those binaries aren't actually used as part of the build and typically we wouldn't have them on our path, so this seems awfully circuitous and I'd prefer the approach in this patch.
Another option I considered is that we could require specifying the CoreCLR location in an environment variable rather than a cmake variable.  But then the spot in our cmakefiles that consult the environment variable would literally be the only use of that variable, so from a user perspective it would be confusing to need to specify this one setting as an environment variable when you can specify all the others as cmake variables.
The best analog that I can think of (to some other cmake default problem) would be how to identify where to find system headers.  Correct me if I'm wrong (I'm new to cmake and haven't developed on *nix in many years), but my understanding is that

- cmake has a considerable amount of logic for sorting that out
- *nix systems default to some fixed paths like /user/include, which doesn't work well here since people can have their coreclr enlistment/binaries wherever they want
- windows/MSVC requires you to set INCPATH &c environment variables, but as mentioned above environment variables don't seem like a good approach here

So that's the line of thinking that led me here.

BTW, thanks a ton for making OPTIMIZED_TABLEGEN a thing, it's a huge win here.


http://reviews.llvm.org/D12679





More information about the llvm-commits mailing list