[PATCH] D82923: introducing llvm-libtool

[Sameer Arora via Phabricator via llvm-commits]

sameerarora101 added a comment.

> 1. Has the introduction of a new tool been discussed on llvm-dev? (I vaguely recall that it might have been but might be getting confused). Please include a link to the mailing thread in the description.

Yup, here is the link for the thread : http://lists.llvm.org/pipermail/llvm-dev/2020-June/142157.html

> 2. Is this significantly different to llvm-ar and its aliases? If so, please outline the differences.

No, it is not significantly different from `llvm-ar` but has good defaults for Apple platforms (e.g. automatically creating a table of contents with the right format). To get the same behavior from `llvm-ar`, we have to explicitly pass additional flags. Furthermore, for archive input files, the individual objects in the input archive are added to the output archive by default by `libtool`. This too requires additional flags in the case of `llvm-ar`.

> 3. Assuming this is going to be developed, could you split off one or two patches that make this even simpler, please. For example, the very first patch would just add the tool with only the built-in --help/--version options, not doing anything useful.
> 4. You may want to consider using cl::opt instead of the tablegen approach you're currently using, since it's simpler and I doubt you need complex logic here.
> 5. There are some basic error handling functions available in the Support library which might do all you need them to. Consider using them before rolling your own.

Ok, got it. Thanks

> 6. Is there going to be non-Darwin versions of this tool? If not, it doesn't need to be located in the Darwin sub-directory.

Quoting from the mailing thread here (http://lists.llvm.org/pipermail/llvm-dev/2020-June/142284.html) :

> An alternative is to plan for the tool to eventually grow to support the features of GNU libtool, allowing a contributor who may become interested in that to work on it within the same code base.

and

> We could take the approach used by LLD and llvm-objcopy, where we create a directory for the tool (llvm/tools/llvm-libtool in this case), and have subdirectories for the ports of the tool (Darwin in our case, and someone interested could create a GNU subdirectory later). That way there's a natural place to put any code that's common between the ports.

@smeenai Please correct me if I highlighted anything wrong above. Thanks!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D82923/new/

https://reviews.llvm.org/D82923