[llvm-dev] contributing llvm-lipo

[Alexander Shaposhnikov via llvm-dev]

Hey everyone!
In October/November 2018 I started the implementation of llvm-objcopy for
MachO with the long-term plan to build some popular binary-level tools on
top of it. That effort stopped at the stage where some boilerplate code for
reading/writing MachO files was reviewed & committed to
LLVM/tools/llvm-objcopy.

Later I started working on llvm-lipo (a drop-in replacing for the tool
"lipo" for manipulating "fat" binaries), but that code has never been sent
for code review. The original plan was to use the approach similar to
llvm-strip, where the new tool is just another "driver" for llvm-objcopy.
This approach worked well for llvm-strip (the command line interface of
llvm-strip maps naturally onto the interface of llvm-objcopy) but turned
out to be not flexible enough for llvm-lipo. The thing is that the tool
lipo doesn't work "per object file", instead, it can have multiple input
files & single output file, no output files at all, etc.

So below is the proposal / request for suggestions how to move forward from
here. It seems to me it might be a good time to try to factor out the
reusable part of llvm-objcopy's codebase and build a library from it. At
the beginning the library can contain : Reader + Object + Writer (for all
the supported formats: ELF/COFF/MachO) and all the tool's specific logic
will stay in place. There are several questions: what would be a good name
for it and how would we want to organize the codebase.

Some options which I can imagine:

A) Leave the code where it is right now, create a library from it,
put llvm-lipo.cpp into the folder llvm/tools/llvm-objcopy

B) Move the code which belongs to the library
out of the folder llvm/tools/llvm-objcopy
and create a new folder llvm/tools/llvm-lipo for the lipo-specific code.

C) Something else ?

D) /* personally don't like */ Try to go with the approach when llvm-lipo
is a symbolic link to llvm-objcopy. This kind of bloats the codebase of
llvm-objcopy,
I don't see many benefits on this path except some space savings.

Any thoughts/suggestions/comments would be appreciated.

Kind regards,
Alex Shaposhnikov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190509/9dba5b5f/attachment.html>