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

[Rui Ueyama]

I've submitted r233313 to remove Makefiles from the repository.

On Mon, Mar 16, 2015 at 11:57 AM, Chris Bieneman <beanz at apple.com> wrote:

>
> 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> 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>
> 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>
>> 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>
>>> 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         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150326/d25d7883/attachment.html>