[PATCH] Add support for a directory argument to llvm-link

[Sean Silva]

On Tue, Mar 18, 2014 at 1:38 PM, Rafael Espíndola <
rafael.espindola at gmail.com> wrote:

> > I meant that I had to use a hack to feed the files to llvm-link (crazy
> > escaping monstrosity), not that the use case is a hack.
>
> Well, it is a hack. That is not how we are implementing lto on trunk.
>

By "use case" I meant "feeding a directory of files to llvm-link", not the
overall script. Feeding a directory of files to llvm-link sounds like a
perfectly normal thing to do.

Besides, making the tool easier to use is not a concession that it should
be used for production purposes or is supported for production purposes;
it's just that: making the tool easier to use. Think about it this way: if
llvm-link were originally written with this behavior, would you be dying to
rip that functionality out?

Khilan, sorry for all this crossfire on your first patch. I'd like to see
another iteration of this patch with the behavior I described:
"Even better: there is no -dir argument. Positional arguments can be either
bitcode files, or directories. If a positional argument happens to be a
directory, it is scanned for bitcode files, which are added to the list of
inputs. It is not an error to specify a directory that contains no bitcode
files."
Actually, I'd prefer an incremental step of just detecting directory
arguments and adding all files in the directory (a future patch can filter
bitcode files if that feature seems useful).

-- Sean Silva



> >> llvm-link is just a developer tool. Any use of it for production
> >> purposes is an unsupported hack. Which sometimes is the right thing to
> >> do, but still a hack and still unsupported.
> >
> >
> > This is a slippery slope. Developer tools exist because they make
> > developers' lives easier. Adding features which make developers' lives
> > easier is the right thing to do. We have concrete experience showing that
> > this sort of feature fits a real use case for the tool and significantly
> > simplifies its use; that's enough reason for me to consider it
> worthwhile to
> > have in-tree (especially since it's a very small amount of logic).
>
> By developer tool I mean something that is use for testing llvm or in
> the day to day tasks of developing llvm. The use case you list is a
> way of implementing LTO which is not how we implement it in tree. I
> think any support code for it should be out of tree too.


> Cheers,
> Rafael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140331/4b1c2727/attachment.html>