[PATCH] D61927: [tools]Introduce llvm-lipo

[Michael Trent via Phabricator via llvm-commits]

mtrent added a comment.

In D61927#1503871 <https://reviews.llvm.org/D61927#1503871>, @alexshap wrote:

> regarding -verify_arch X Y Z - yeah, I can try to make it work with LLVM's command line options parser, not sure if this interface is ideal / better than -verify_arch X -verify_arch Y -verify_arch Z, but yeah, on the other hand, this would be an incompatibility / would require customers of the old tool to update their scripts/code.  The downside of the old interface - the positional argument should go before -verify_arch. To be honest at the moment I don't see how to express the old behavior of -verify_arch using libCommandLine, any suggestions would be helpful, alternatively we can try to live with this incompatibility.


Well, let's have a look at Apple's command syntax. I re-wrote the man page for the latest release, so it's a little clearer to see what's going on. I'll summarize here.

These commands/options take no arguments and are no trouble at all for llvm's command-line parser: -archs, -detailed_info, -info, -hideARM64

These commands/options take a single argument, and only one of these options is allowed. Again, easy mode: -thin, -output.

These commands take a single argument, and any number of them can appear (as long as this is the only such command that appears). Easy mode, you have to handle the command exclusivity yourself in your command driver anyway, so that's not really any extra work: -extract, -extract_family, -remove,

These commands / options take a fixed number of arguments, where n > 1: -create, -replace, -arch, -segalign. I'm under the impression this is something llvm does not support of the box, because we see this problem wtih "llvm-nm -s". But it's possible that the "AdditionalVals" parameter on class Option is meant to deal with this situation. But, if so, no one has circled back to llvm-nm. Some of these commands are pretty critical.

And this command is the worst of the bunch, taking any number of arguments. It's also the one you implemented first :): -verify_arch.

Looking ahead to your task of making a drop-in replacement for Apple's lipo, you're going to have to tackle -verify_arch, -create, -replace, -arch, and -segalign. That's a non-trivial surface area of the lipo tool. My advice is to see if you can model the complete set of lipo command-line options you want to reverse-engineer -- don't worry about implementing the feature, just parse the arguments. If -verify_arch is the only one that doesn't fit the mold, I think "just live with it" is the right call. But if you can't get -create to work with an arbitrary number of -arch or -arch_blank options, or if you can't get -replace working, you're going to have trouble making a viable "drop-in-replacement."

HTH!


Repository:
  rL LLVM

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

https://reviews.llvm.org/D61927