Therefore, I recommend removing the SubCommand parameter from this API and always using cl::TopLevelSubCommand.

@hintonda / @beanz : I've been thinking about this, and I'm now convinced that this review is probably not the good approach. What we need is a good way to track which options are actually important for a given binary, correctly set the categories of each option and *reallyhide* the others. So I'll pause this review and start working on sanitizing the output of several tools until I get a better understanding of the actual API needs.

@beanz

I expect that we will want to use cl::HideUnrelatedOptions in a lot more places to clean up other tool help messages.

That's indeed the plan.

@lebedev.ri doc updated.

Updated with clang-formated diff

@hintonda I've updated the patch taking your advices into account. I took a step ahead and applied the non-conservative signature change for cl::HideUnrelatedOptions

@hintonda this looks better that way, for sure.

It was added in D7100, and I think the rational was to hide implementation details.

@Meinersbur I'll be happy to read your feedback on windows compilation!

For reference, and following the idea that we should not filter out relevant options, her eis the original output:

Include full context

I will have to try out the patch, e.g. on Windows. Please ping me if it takes to long.

Thanks @Meinersbur

Up!

Up!

@mehdi_amini I've updated the .tgz sample so that one could see that the expected CMakelists.txt for third-party compiler extensions is now super-simple.

Update diff to make it less intrusive: using a declarative approach, each compiler extension registers itself as an extension, and thanks to cmake-generator-expression, it's possible to delay the evaluation of linked extensions until all extensions registered.

@Meinersbur, I've tested and reviewed this patch, I'm curious about Polly's team opinion on the changes in current state?
@mehdi_amini, Did I correctly capture your remarks on llvm-projects?

Tested withe the following dummy project: https://sergesanspaille.fedorapeople.org/bye.tgz

Update diff to make it compatible with llvm projects.

Do you intent to use this interface for a specific external project, or is it to avoid direct references to Polly?

Patch update:

• make it possible for extension to register extra tool dependency
• accept the all target to automatically detect official extensions (namely Polly as of now)
• ship clang patch

@rsmith : up :-)

@jhenderson I've added a few potential reviewers based on the file history.

Including test case

Without category filtered:

Fun fact: when --help is active, no error is reported for invalid options :-) Fixed.

Splitting on a character would make a lot of sense. Most tools use '=' or similar for multi-string arguments.

Update test

alias don"t need to be marked as part of a category, this makes the diff shorter. Same for positional argument. New output:

@chandlerc up!

GNU as compatibility totally makes sense, dropping the patch, and thanks for the detailed answer!

Obsoleted by r357471

@rsmith : up :-)

@rnk, @mcrosier : up :-)

Yep, that's clearly a duplicate that was hanging around in my patch list, sorry for the noise.

@rsmith up!

@michaelplatings up!

Closed by https://reviews.llvm.org/rL356904

@davide : is that ok if I add you to a few other python compat related reviews?

validates fine on my side with py3

I didn't run the check-lldb target though, I'm doing that right now.

@davide I first applied 2to3 systematically, then manually edited the diff so that it remains backward compatible with python2.

Thanks for the review! I've started to work on lldb python code base, and with that we should have all Python files for llvm, clang, lld and lldb compatible with Python2 and Python3.