[LLVMdev] RFC: I plan to remove the autoconf and Makefile build of LLD

Mon Mar 16 11:57:08 PDT 2015

> On Mar 16, 2015, at 4:59 AM, Iain Sandoe <iain at codesourcery.com> wrote:
> 
> Hi Chris,
> 
> On 14 Mar 2015, at 21:42, Chris Bieneman wrote:
> 
>> Just out of curiosity. The community generally seems to be moving away from autoconf toward CMake. Is there a reason why you need the autoconf build bad enough to support it out-of-tree?
> 
> The reasons a short-term and boring engineering/project-related, rather than ideological.

Gotcha.

> 
> We all agree that one well-maintained build system is desirable; FAOD I have no axe to grind over which it is - providing it supports the hosts, targets and use-cases we care about. 
> 
>> Today supporting LLD’s autoconf build out-of-tree probably isn’t that bad because LLD is fairly small and LLVM still has a functioning autoconf build system. However, if LLVM moves off autoconf (and you’re stuck on it for some reason) you may be in the awful position of needing to support LLVM’s autoconf build out-of-tree, which would be pretty terrible.
> 
> I suspect that the typical  development-builder of the compiler is interested in a self-host on one host platform, possibly with limitation to one (or maybe two) revisions of the host system (there are exceptions, of course) .. 
> 
> That is considerably different from our use-case; we support a wide range of toolchains across several platforms (and often quite wide ranges of versions).  We are building integrated toolchains with a bunch of components from several sources (including internal and client-provided).  It is expected by some of our clients that these will be supportable for possibly years to come.
> 
> It's completely impracticable to support that kind of arrangement with an array of different host boxen with a second array of configurations; ergo our usual use-case is cross (or, in some cases, "canadian") builds.

My team primarily cross compiles LLVM from OS X to arm, so that isn’t too far fetched of a use case. I’ve actually upstreamed almost all our CMake goop to make it work, and am actively supporting cross-compilation in the CMake build system. There are some issues still with compiler-rt, but I’m hopeful we can get those worked out eventually too.

> 
> Perhaps not surprisingly, we have a significant system to handle build, test, QA and release of these toolchains.  At present, there is no other call for cmake in that system and none of the LLVM projects in my group have any resources assigned to switching to the build/test/etc. to use cmake.
> 
> Thus, in the short-term (since, as you say, things are currently simple) local maintenance of the lld makefiles is the most economical approach.
> 
> We continually review the situation internally and all the folks you see contributing regularly to llvm, clang and lldb have WIP cmake implementations.  I hope that we can get that stuff in place before the plug is finally pulled on autoconf.

I don’t think this is imminent, but I really would love to have autoconf given the boot this year.

> 
>> If there is a deficiency in the CMake build system that keeps you from using it, we should track that as a blocker for removing autoconf from LLVM and address it.
> 
> My observation is that, if one strays from the "beaten path" (which I equate to self-host on one platform) - with either cmake or auto-fu, then things tend not to work completely (or as you might expect)  :-) ... 
> .. thus I expect we'll need to do some maintenance either way - but that's life!

If you have specific issues I’d be more than happy to help. I’m very interested in making CMake better for cross compilation.

> 
> Apologies if I sounded grumpy,

Anyone who messes with build systems is entitled to a healthy bit of grump — I know I take more than my fair share :-).

-Chris

> Iain
> 
>> 
>> Thanks,
>> -Chris
>> 
>>> On Mar 13, 2015, at 12:23 PM, Iain Sandoe <iain at codesourcery.com <mailto:iain at codesourcery.com>> wrote:
>>> 
>>> I fixed the immediate problem - please let me know when you are going to break my build so I can switch to maintaining it locally.
>>> thanks
>>> Iain
>>> ]
>>> On 13 Mar 2015, at 17:04, Rui Ueyama wrote:
>>> 
>>>> Looks like most developers prefer Makefile removal, and there's no push-back. Let's go ahead and remove them. I'll send a patch.
>>>> 
>>>> On Wed, Mar 11, 2015 at 3:33 PM, Iain Sandoe <iain at codesourcery.com <mailto:iain at codesourcery.com>> wrote:
>>>> I have fixed the issue locally, but been out of the office - can apply the fix - or just maintain the makefiles locally if no-one else really wants them,
>>>> 
>>>> fine with whatever the community decision is.
>>>> Iain
>>>> 
>>>> On 11 Mar 2015, at 22:11, Rui Ueyama wrote:
>>>> 
>>>>> I'd agree, but the Makefiles were added just 9 months ago. I don't know if there's a real need of any kind. Added Iain who added these files.
>>>>> 
>>>>> On Wed, Mar 11, 2015 at 3:10 PM, Chandler Carruth <chandlerc at gmail.com <mailto:chandlerc at gmail.com>> wrote:
>>>>> This time with the correct mailing list address... See below...
>>>>> 
>>>>> On Wed, Mar 11, 2015 at 3:07 PM, Chandler Carruth <chandlerc at gmail.com <mailto:chandlerc at gmail.com>> wrote:
>>>>> Why?
>>>>> 
>>>>> 1) We're moving away from autoconf already today. We're hoping to drop it completely soon.
>>>>> 2) It doesn't work today and no one is complaining.
>>>>> 3) It hasn't worked for weeks and no one has complained.
>>>>> 
>>>>> Due to #2 and #3, I believe it is dead code. I can't even test my changes to it because it doesn't work.
>>>>> 
>>>>> I don't want to invest time fixing it if we're moving the other direction.
>>>>> 
>>>>> -Chandler
>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu>         http://llvm.cs.uiuc.edu <http://llvm.cs.uiuc.edu/>
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev <http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150316/74538567/attachment.html>