[lld] Makefiles for lld.

Eric Christopher echristo at gmail.com
Fri May 30 13:23:20 PDT 2014


On Fri, May 30, 2014 at 6:51 AM, Iain Sandoe <iain at codesourcery.com> wrote:
> Hi Alp,
>
> On 29 May 2014, at 21:50, Alp Toker wrote:
>
>> On 29/05/2014 22:32, Eric Christopher wrote:
>>> The motivation for this is that we have two build systems already,
>>> they're easy to keep up to date anyhow, and we do this for the rest of
>>> llvm.
>>
>> The concern with multiple build systems is more to do with the chilling effect.
>>
>> We all know that feeling when you *should* go and fix it, only that you don't have a Makefile build around, or you're on Windows / BSD or some place, so you just end up lumping things into an existing module that happens to already exist in both.
>>
>>>
>>> Otherwise it's motivating for people to get us to one build system so
>>> they don't have to do the work :)
>>
>> A better motivator would be to cite the remaining issues with CMake.
>
> that's a good idea.
>
> ..  my (probably flawed) understanding is that there are known issues with phasing build dependencies that are already being addressed upstream.  However, I will defer to someone who knows the facts.
>
> Personally, I currently have external constraints that predicate using the config & make solution .. and offer the Makefiles upstream in case anyone else can similarly benefit (for the last year or so I've been using them locally).
>
>> I always feel that we're missing out on cool stuff like better DLL / shared builds and various bits of module cleanup because whoever takes on the challenge would have to implement it twice, compatibly, which stops being fun.
>
> My 0.02GBP is that if we are worried that a working solution to a problem today will prevent people implementing a better solution tomorrow, then we have a wider issues to address than a few Makefiles ;)
>
> anyway, the files are posted if anyone wants them.
>

Yep. Do you have commit access? Should we just wait on Michael's
reworking of the build first (I assume you'll be keeping them up to
date either way, but...)

-eric

> cheers
> Iain
>
>>
>> Alp.
>>
>>
>>>
>>> -eric
>>>
>>> On Thu, May 29, 2014 at 12:30 PM, Nick Kledzik <kledzik at apple.com> wrote:
>>>> What is the motivation for this?  And who is expected to keep them up to date as lld evolves?  Currently, everyone working on lld uses the cmake system.
>>>>
>>>> -Nick
>>>>
>>>> On May 28, 2014, at 8:08 AM, Iain Sandoe <iain at codesourcery.com> wrote:
>>>>> Hi Eric,
>>>>>
>>>>> sorry this took so long, (other things just kept creeping up the TODO).
>>>>>
>>>>> This is a set of Makefiles based on the approach(es) used elsewhere in the tree.
>>>>> I've been using these for quite a while on both OSX and Linux with either clang or GCC as the bootstrap compiler.
>>>>>
>>>>> With this patch, lld will build (with autoconf & make) when it is found in llvm/tools (using the same approach as lldb).
>>>>>
>>>>> Right now, as with lldb, there's no more finesse than that (i.e. there's no way to switch lld on/off other than directory presence/absence in tools/).
>>>>>
>>>>> The lld tests are added to check-all.
>>>>>
>>>>> does this seem like a reasonable starting point?
>>>>> cheers
>>>>> Iain
>>>>>
>>>>> <lld-add-build-with-make.txt>
>>>>>
>>>>> _______________________________________________
>>>>> llvm-commits mailing list
>>>>> llvm-commits at cs.uiuc.edu
>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>> _______________________________________________
>>> llvm-commits mailing list
>>> llvm-commits at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>
>> --
>> http://www.nuanti.com
>> the browser experts
>>
>



More information about the llvm-commits mailing list