[llvm-dev] RFC: Contributing llvm-libtool (LLVM version of Apple's libtool)

[Shoaib Meenai via llvm-dev]

We're planning to contribute an LLVM version of Apple's libtool utility. To quote its man page, "Libtool with -static is intended to replace ar(5) and ranlib". In other words, libtool is the preferred tool to create archives for Apple platforms, and it also has good defaults for that platform (e.g. automatically creating a table of contents with the right format). It provides a convenient interface for developers, and we have a lot of usage of it (instead of ar) for that reason in various builds. In particular, it handles universal and archive input files well; for universal input files, you can either specify a single architecture or have libtool create a universal output file, and for archive input files, the individual objects in the input archive are added to the output archive. LLVM's build system uses libtool on Apple platforms to handle universal binaries correctly, for example.
 
To be clear, we're *not* planning to contribute an equivalent to GNU libtool, which has the same name but (as far as I can tell) a very different scope. Any naming ideas to avoid confusion on this front would be appreciated.
 
One design point we'd appreciate input on is how to structure this new tool. Apple's libtool supports creating either static or dynamic libraries. It produces static libraries directly, but for dynamic libraries, it calls the linker. Our initial focus and contribution will be the functionality for static libraries, but we want our design to take the possibility of the dynamic library generation being added later into account. For this reason, we're planning to create llvm-libtool as a standalone tool instead of as a frontend for llvm-ar. (llvm-ranlib is an example of a frontend for llvm-ar, where it's the same underlying binary which just does different option parsing depending on how it's invoked.) Much of the archive writing logic that llvm-ar uses is already factored out to libObject (the writeArchive function), and we can factor more of it out as needed, so we shouldn't end up with too much duplicated code between llvm-ar and llvm-libtool. At the same time, making llvm-libtool its own tool gives us the freedom to e.g. factor out parts of llvm-lipo into a library to handle universal inputs and outputs directly in llvm-libtool rather than having to invoke lipo separately, handle dynamic library generation in a natural way (whereas it would be odd for llvm-ar to contain code for generating dynamic libraries if we were to make llvm-libtool a frontend for llvm-ar, since llvm-ar is a tool specifically for creating archives), and potentially integrate with LLD for Mach-O as a library in the future instead of spawning the linker separately. Are there any concerns with this plan?