<div dir="ltr"><span style="color:rgb(0,0,0);white-space:pre-wrap">Hey everyone!</span> <div>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. </div><div><br></div><div>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.  </div><div><br><div>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. </div></div><div><br></div><div>Some options which I can imagine:</div><div><br></div><div>A) Leave the code where it is right now, create a library from it, </div><div>put llvm-lipo.cpp into the folder llvm/tools/llvm-objcopy </div><div><br></div><div><div>B) Move the code which belongs to the library </div><div>out of the folder llvm/tools/llvm-objcopy</div><div>and create a new folder llvm/tools/llvm-lipo for the lipo-specific code.</div></div><div><br></div><div>C) Something else ?</div><div><br></div><div>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,</div><div>I don't see many benefits on this path except some space savings.</div><div><br></div><div>Any thoughts/suggestions/comments would be appreciated.</div><div><br></div><div>Kind regards,</div><div>Alex Shaposhnikov</div><br class="gmail-Apple-interchange-newline"></div>