[lld] Makefiles for lld.

[Iain Sandoe]

Hi Eric,

On 30 May 2014, at 21:23, Eric Christopher wrote:

> 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?

yes.

> Should we just wait on Michael's
> reworking of the build first

if that's happening "tomorrow", then maybe .. 
.. if it's further away, then i'd prefer to have the stuff out in the wild.

> (I assume you'll be keeping them up to
> date either way,

right, which is easier to do when the changes are incremental.

cheers
Iain

> 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
>>> 
>>