- User Since
- Oct 10 2016, 10:44 AM (135 w, 6 d)
Fri, May 17
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.
Thu, May 16
Wed, May 15
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
Tue, May 14
@hintonda this looks better that way, for sure.
Mon, May 13
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:
Fri, May 10
Include full context
I will have to try out the patch, e.g. on Windows. Please ping me if it takes to long.
Thu, May 9
@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.
Wed, May 8
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.
Tue, May 7
Tested withe the following dummy project: https://sergesanspaille.fedorapeople.org/bye.tgz
Mon, May 6
Update diff to make it compatible with llvm projects.
Fri, May 3
Do you intent to use this interface for a specific external project, or is it to avoid direct references to Polly?
- 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
Thu, May 2
Tue, Apr 30
@rsmith : up :-)
Apr 12 2019
@jhenderson I've added a few potential reviewers based on the file history.
Including test case
Without category filtered:
Apr 11 2019
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.
Apr 10 2019
alias don"t need to be marked as part of a category, this makes the diff shorter. Same for positional argument. New output:
% ./bin/llvm-nm --help OVERVIEW: llvm symbol table dumper
Apr 8 2019
Apr 5 2019
Apr 3 2019
GNU as compatibility totally makes sense, dropping the patch, and thanks for the detailed answer!
Apr 2 2019
Obsoleted by r357471
@rsmith : up :-)
Mar 28 2019
Yep, that's clearly a duplicate that was hanging around in my patch list, sorry for the noise.
Mar 26 2019
Mar 25 2019
Closed by https://reviews.llvm.org/rL356904
Mar 23 2019
Mar 21 2019
@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.
Mar 20 2019
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.