r213010 - Define ENABLE_CLANG_ARCMT in the legacy build system too
Richard Smith
richard at metafoo.co.uk
Tue Jul 15 20:31:55 PDT 2014
On Tue, Jul 15, 2014 at 5:33 PM, Alp Toker <alp at 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 <alp at nuanti.com
>>> <mailto:alp at nuanti.com>> wrote:
>>>
>>>
>>> On 16/07/2014 00:38, Nico Weber wrote:
>>>
>>> On Tue, Jul 15, 2014 at 10:08 AM, Alp Toker <alp at nuanti.com
>>> <mailto:alp at nuanti.com> <mailto:alp at nuanti.com <mailto:
>>> alp at nuanti.com>>>
>>> wrote:
>>>
>>>
>>> On 15/07/2014 05:07, Nico Weber wrote:
>>>
>>> On Mon, Jul 14, 2014 at 4:15 PM, Alp Toker <
>>> alp at nuanti.com
>>> <mailto:alp at nuanti.com>
>>> <mailto:alp at nuanti.com <mailto:alp at nuanti.com>>
>>> <mailto:alp at nuanti.com <mailto:alp at nuanti.com>
>>>
>>> <mailto:alp at nuanti.com <mailto:alp at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140715/548ae8cf/attachment.html>
More information about the cfe-commits
mailing list