<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi Chris,<div><br><div><div>On 14 Mar 2015, at 21:42, Chris Bieneman wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">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?</div></blockquote><div><br></div><div>The reasons a short-term and boring engineering/project-related, rather than ideological.</div><div><br></div><div>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. </div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">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.</div></div></blockquote><div><br></div><div>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) .. </div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Thus, in the short-term (since, as you say, things are currently simple) local maintenance of the lld makefiles is the most economical approach.</div><div><br></div><div>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.</div><div><br></div><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">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.</div></div></blockquote><div><br></div>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) :-) ... </div><div>.. thus I expect we'll need to do some maintenance either way - but that's life!</div><div><br></div><div>Apologies if I sounded grumpy,</div><div>Iain</div><div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">Thanks,</div><div class="">-Chris</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 13, 2015, at 12:23 PM, Iain Sandoe <<a href="mailto:iain@codesourcery.com" class="">iain@codesourcery.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; " class="">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.<div class="">thanks</div><div class="">Iain</div><div class="">]<br class=""><div class=""><div class="">On 13 Mar 2015, at 17:04, Rui Ueyama wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite" class=""><div dir="ltr" class="">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.</div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Wed, Mar 11, 2015 at 3:33 PM, Iain Sandoe <span dir="ltr" class=""><<a href="mailto:iain@codesourcery.com" target="_blank" class="">iain@codesourcery.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="">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,<div class=""><br class=""></div><div class="">fine with whatever the community decision is.</div><span class="HOEnZb"><font color="#888888" class=""><div class="">Iain</div></font></span><div class=""><div class="h5"><div class=""><br class=""></div><div class=""><div class=""><div class=""><div class=""><div class="">On 11 Mar 2015, at 22:11, Rui Ueyama wrote:</div><br class=""><blockquote type="cite" class=""><div dir="ltr" class="">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.<br class=""></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Wed, Mar 11, 2015 at 3:10 PM, Chandler Carruth <span dir="ltr" class=""><<a href="mailto:chandlerc@gmail.com" target="_blank" class="">chandlerc@gmail.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="">This time with the correct mailing list address... See below...<div class=""><div class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Wed, Mar 11, 2015 at 3:07 PM, Chandler Carruth <span dir="ltr" class=""><<a href="mailto:chandlerc@gmail.com" target="_blank" class="">chandlerc@gmail.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="">Why?<div class=""><br class=""></div><div class="">1) We're moving away from autoconf already today. We're hoping to drop it completely soon.</div><div class="">2) It doesn't work today and no one is complaining.</div><div class="">3) It hasn't worked for weeks and no one has complained.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">I don't want to invest time fixing it if we're moving the other direction.</div><span class=""><font color="#888888" class=""><div class=""><br class=""></div><div class="">-Chandler</div></font></span></div>
</blockquote></div><br class=""></div></div></div></div>
</blockquote></div><br class=""></div>
</blockquote></div><br class=""></div></div></div></div></div></div></blockquote></div><br class=""></div>
</blockquote></div><br class=""></div></div>_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:LLVMdev@cs.uiuc.edu" class="">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu/" class="">http://llvm.cs.uiuc.edu</a><br class=""><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" class="">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br class=""></div></blockquote></div><br class=""></div></div></blockquote></div><br></div></body></html>