On Tue, Oct 2, 2012 at 1:34 PM, Bill Wendling <[email protected]> wrote: > On Oct 2, 2012, at 11:49 AM, David Blaikie <[email protected]> wrote: > >> On Tue, Oct 2, 2012 at 11:39 AM, Bill Wendling <[email protected]> wrote: >>> On Oct 2, 2012, at 11:35 AM, David Blaikie <[email protected]> wrote: >>> >>>> On Mon, Oct 1, 2012 at 11:19 PM, Bill Wendling <[email protected]> wrote: >>>>> Author: void >>>>> Date: Tue Oct 2 01:19:15 2012 >>>>> New Revision: 164992 >>>>> >>>>> URL: http://llvm.org/viewvc/llvm-project?rev=164992&view=rev >>>>> Log: >>>>> Use an environment variable instead of what's in the make cmd goals. >>>> >>>> Still makes me sad that this is an environment variable (admittedly >>>> this isn't important - just an aesthetic issue for me) >>> >>> I know. I tried to make it work, but couldn't. The thing is that clang is >>> built with MAKECMDGOALS == all, and not 'clang-only', which I would prefer. >> >> Where's that MAKECMDGOALS value coming from? just the LLVM build >> invoking the Clang build? >> > It's set automatically by the 'make' program. So if you do this: > > make fnord > > the MAKECMDGOALS will be 'fnord'. When we build clang it's set to 'all' > because that's how the whole build system seems to work... > >>> So I had to default to making it a variable. :-( >>> >>>> - what's the >>>> use case for this? It just seems like this should naturally fall out >>>> from any build command that wants to just build clang. If it doesn't >>>> then someone may get sub-optimal builds because they don't know about >>>> this environment variable they need to use. >>> >>> This is for building clang with LTO and wanting only the clang and clang++ >>> executables and libraries (no tools, etc.). The problem here is that LTO >>> takes a *long* time to link things because of how much memory it takes. >>> Building anything extraneous is a waste here. >> >> Yeah, I figured it was something like that - my point was that while >> it's a big waste for this case, it's a small waste for every other >> user that wants to just build the Clang installation binaries & >> doesn't use this flag. >> > True. But they don't need to know about the flag. :) Here's the code in the > top-level Makefile: > > ifeq ($(MAKECMDGOALS),clang-only) > BUILD_CLANG_ONLY := YES > DIRS := $(filter-out tools docs unittests, $(DIRS)) \ > tools/clang tools/lto > OPTIONAL_DIRS := > endif > >>> What I did is link this environment variable with the 'clang-only' flag >>> (see equivalent patch on llvm-commits). When someone specifies 'make >>> clang-only', they won't get the other stuff. >> >> Hmm, OK - I'm not quite sure how that works just looking at the LLVM >> Makefile, but I'll keep an eye out for the patch as I work through my >> email backlog. If it does the right thing for any LLVM make target >> then I can't complain too much - just a minor implementation wart at >> that point. >> > I forgot to check the code in. (>.<) It's there now.
;) Makes sense now, thanks. (idly: I wonder if the CMake build does this any better/more finely-grained so that the outer build can build just the bits it needs from clang, depending on the target.) - David _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
