[LLVMdev] [lld] lld build needs to have flags that specify what flavor/targets to build ?

[Michael Spencer]

On Tue, Oct 7, 2014 at 2:31 PM, Rui Ueyama <ruiu at google.com> wrote:
> On Tue, Oct 7, 2014 at 2:22 PM, Shankar Easwaran <shankare at codeaurora.org>
> wrote:
>>
>> On 10/7/2014 4:10 PM, Nick Kledzik wrote:
>>>
>>> Shankar,
>>>
>>> Can you give provide a scenario where you want this?  I’m not sure what
>>> you want here.
>>
>>
>> a) LLVM could be built  just for one target(LLVM_TARGETS_TO_BUILD)
>> b) With LTO this case might happen more often, where an user would have
>> compiled LLVM just for one architecture and lld would support other
>> architectures that LLVM would not support.
>> c) Printing all the targets/flavors that the linker currently supports.
>
>
> What's the motivation to build a LLD only for some specific target? Size?
>
> LLD is not a large executable. When compiled with Release, it's a few
> megabyte binary. If you kill architectures that you don't need, you won't
> save that much.
>
> On the other hand, making something configurable always comes with cost.
> It's not hard to imagine that we would get a bug reports that "feature X
> didn't work if we build LLD only for target Y."

Agreed. I'm fine with having a runtime way to not expose specific
targets in the case you want to ship lld to customers and don't want
to imply you support the other targets.

- Michael Spencer

>
>> On Oct 7, 2014, at 2:03 PM, Shankar Easwaran <shankare at codeaurora.org>
>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> I think lld needs to have an infrastructure as part of the build process
>>>> to build specific flavors and specific targets.
>>>
>>> This sounds like you want config-time choices (e.g. build a linker to
>>> only support ELF/x86 such as for a JIT).
>>
>> Yes.
>>
>>>> For this I was thinking that the Registry expand to consider flavors and
>>>> targets that are part of the build process.
>>>>
>>>> So each flavor/target would register and the Driver would walk through
>>>> the list of handlers to check if there is a handler defined for that
>>>> flavor/target.
>>>
>>> This sounds like you want everything decided at runtime (e.g. all flavors
>>> registers all readers).
>>
>> Yes, right.
>>
>>
>> Shankar Easwaran
>>
>> --
>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted
>> by the Linux Foundation
>>
>>
>