On Tue, Jul 15, 2014 at 5:33 PM, Alp Toker <a...@nuanti.com> wrote: > > On 16/07/2014 02:38, Jonathan Roelofs wrote: > >> >> >> On 7/15/14, 3:22 PM, Nico Weber wrote: >> >>> On Tue, Jul 15, 2014 at 3:07 PM, Alp Toker <a...@nuanti.com >>> <mailto:a...@nuanti.com>> wrote: >>> >>> >>> On 16/07/2014 00:38, Nico Weber wrote: >>> >>> On Tue, Jul 15, 2014 at 10:08 AM, Alp Toker <a...@nuanti.com >>> <mailto:a...@nuanti.com> <mailto:a...@nuanti.com <mailto: >>> a...@nuanti.com>>> >>> wrote: >>> >>> >>> On 15/07/2014 05:07, Nico Weber wrote: >>> >>> On Mon, Jul 14, 2014 at 4:15 PM, Alp Toker < >>> a...@nuanti.com >>> <mailto:a...@nuanti.com> >>> <mailto:a...@nuanti.com <mailto:a...@nuanti.com>> >>> <mailto:a...@nuanti.com <mailto:a...@nuanti.com> >>> >>> <mailto:a...@nuanti.com <mailto:a...@nuanti.com>>>> >>> 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 >>> <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.) >>> >> >> ISTR hearing discussion about there being difficulty getting CMake to use >> the just-built-clang to build compiler_rt. Until that's resolved, that kind >> of makes CMake dead in the water for cross builds... >> > > This sounds a little suspect. LLVM/clang is compiled to run on the build > host (a specific architecture), whereas runtime libraries are built by the > user/middleware vendor to run on any one of many possible target machines > (e.g. a mobile phone or dishwasher, requiring its own build environment, > SDK, headers etc.) >
This was a real issue (for the overwhelming common case of building a non-cross-compiler), but has been solved for about a year, if memory serves. The fact they both have build systems or contain source code is incidental > -- the latter is really just user data at the point the toolchain and no > build system integration is possible. Perhaps CMake pulled in the wrong > folder by mistake due to a bad SVN checkout? See this thread for some problems with removing the configure/make build system, that may or may not have been resolved: http://lists.cs.uiuc.edu/pipermail/cfe-dev/2012-June/022376.html and in particular: http://lists.cs.uiuc.edu/pipermail/cfe-dev/2012-June/022419.html http://lists.cs.uiuc.edu/pipermail/cfe-dev/2012-June/022558.html http://lists.cs.uiuc.edu/pipermail/cfe-dev/2012-June/022426.html http://lists.cs.uiuc.edu/pipermail/cfe-dev/2012-June/022432.html We also still list the configure/make build system as the canonical one in the 'getting started' guide: http://clang.llvm.org/get_started.html#build There is definitely consensus that we want to get rid of the configure/make build system eventually. Maybe the time has come to have that discussion again? The 3.5 release is approaching; if we want to include a release note saying "this is the last release that will have a configure-based build system", now would be the time.
_______________________________________________ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
