On Tue, Jul 15, 2014 at 3:07 PM, Alp Toker <[email protected]> wrote: > > On 16/07/2014 00:38, Nico Weber wrote: > >> On Tue, Jul 15, 2014 at 10:08 AM, Alp Toker <[email protected] <mailto: >> [email protected]>> wrote: >> >> >> On 15/07/2014 05:07, Nico Weber wrote: >> >> On Mon, Jul 14, 2014 at 4:15 PM, Alp Toker <[email protected] >> <mailto:[email protected]> <mailto:[email protected] >> >> <mailto:[email protected]>>> wrote: >> >> Author: alp >> Date: Mon Jul 14 18:15:48 2014 >> New Revision: 213010 >> >> URL: http://llvm.org/viewvc/llvm-project?rev=213010&view=rev >> Log: >> Define ENABLE_CLANG_ARCMT in the legacy build system too >> >> >> As far as I know, make is just as supported as cmake, no? >> >> >> Not really. it hasn't seen any of the feature work CMake has for >> at least a year. You only need to look at SVN logs to see all the >> hard work and hours spent on the CMake setup to make it outclass >> the other setup. >> >> >> Or to see that the CMake build is maintenance for some reason ;-) >> >> >> Platform support is limited compared to CMake, likewise >> cross-compilation has been left behind thanks to the remarkable >> CMake sub-invocation work. No compilation database generation, >> meaning a poor experience for anyone trying to use tooling on the >> codebase. Broken dependency scanning, you have to "touch" files or >> risk getting miscompiles. And there are many Windows developers >> contributing these days -- their enhancements basically only ever >> get added to CMake while Makefiles are left with minimal build fixes. >> >> Then there's bit rot. Various clang tests aren't supported with >> the 'makefiles' build -- they're simply not run -- the set of >> installed headers isn't necessarily canonical with makefiles >> either. Whenever I've pinged that makefiles need to track some >> change or other, nobody's been too interested in following up. So >> users really aren't getting the "full LLVM experience" with it at >> this point, the 'makefiles' bots aren't getting full coverage etc. >> >> As far as I can tell it would take a large effort to get the >> traditional build system on par with CMake at this point and >> nobody's puting in the time to actually do that. While supported, >> the old system definitely meets the definition of "legacy". Only >> commits could have changed that, not any amount of hand waving or >> arguing that it's still the default in "buildit" :-) >> >> >> Sounds like you prefer the cmake build, >> > > No, I mean it really isn't that well supported.
There's a buildbot that uses it, and people fix it if it breaks. (See e.g. this change.) (Note that I'm not particularly attached to the make build – if the llvm project decides to drop make and only keep cmake around, I wouldn't argue against that. But that hasn't happened yet.) > but there wasn't some thread about this that I missed. So please just say >> "in make" instead of "legacy build system" (it's more concise, too!) >> > > "in make"? That's a new one :-) > Maybe "with make"? "for make"? I don't speak English, but there's probably some verbal construct to express the sentiment I'm going for :-) > > > > > > > > >> >> >> >> >> >> Modified: >> cfe/trunk/tools/libclang/Makefile >> >> Modified: cfe/trunk/tools/libclang/Makefile >> URL: >> http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/ >> libclang/Makefile?rev=213010&r1=213009&r2=213010&view=diff >> ============================== >> ================================================ >> --- cfe/trunk/tools/libclang/Makefile (original) >> +++ cfe/trunk/tools/libclang/Makefile Mon Jul 14 18:15:48 >> 2014 >> @@ -37,6 +37,10 @@ ifeq ($(HOST_OS), $(filter $(HOST_OS), L >> LLVMLibsOptions += >> -Wl,-soname,lib$(LIBRARYNAME)$(SHLIBEXT) >> endif >> >> +ifeq ($(ENABLE_CLANG_ARCMT),1) >> + CXX.Flags += -DCLANG_ENABLE_ARCMT >> +endif >> + >> ##===------------------------- >> ---------------------------------------------===## >> # FIXME: This is copied from the 'lto' makefile. Should >> we share >> this? >> ##===------------------------- >> ---------------------------------------------===## >> >> >> _______________________________________________ >> cfe-commits mailing list >> [email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>> >> >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits >> >> >> >> -- http://www.nuanti.com >> the browser experts >> >> >> > -- > http://www.nuanti.com > the browser experts > >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
