[cfe-dev] [llvm-dev] Is there precedent for customizing clang -help output in a toolchain specific way

[Andrzej Warzynski via cfe-dev]

Hey Todd,

Sadly I've not had the bandwidth to look into this more. I've simply 
tweaked PrintHelp() via clang::driver::options::ClangFlangs (I added an 
extra flag for Flang). The other options (i.e. irrelevant for Flang) are 
always there (i.e. present in OptTable) - we only control what's 
displayed via `-help`. Perhaps this is _the canonical_ solution to this? 
IIUC, that's what you've tried to begin with.

I share your observation - anything more sound (e.g. constructing 
customized OptTable) requires non-trivial refactoring. However, I've 
noticed that parsing of command line options is already quite optimised 
and I'm not convinced that trimming OptTable would be beneficial. But 
I'd have to dive a bit deeper into this.

I've recently shared our updated plan for the Flang driver on cfe-dev 
[1]. There's a section on options too, though it's more or less what we 
discussed here already. Tl;Dr We'd like to refactor libclangDriver a 
bit, but that's excluding the toolchain options.

-Andrzej

[1] http://lists.llvm.org/pipermail/cfe-dev/2020-July/066393.html

On 05/08/2020 16:26, Snider, Todd wrote:
> 
> Hi Andrzej,
> 
> I've been playing around with a couple of approaches to allow a toolchain to take control of the content of the -help output, but I'm not thrilled with the results.
> 
> The general approach that I've tried is to have a toolchain-specific version of PrintHelp() create its own OptTable either by filtering the OptTable generated from Options.td or by using a toolchain-specific version of Options.td that contains only the options and HelpText fields that the toolchain wants in the -help output. Each of these approaches has to mess with a generic API in some way (either the OptTable API or the Driver API).
> 
> Have you had some success in your attempts to customize Driver::PrintHelp()? I'd be interested to learn what you've tried.
> 
> ~ Todd
> 
> -----Original Message-----
> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Andrzej Warzynski via llvm-dev
> Sent: Monday, July 27, 2020 3:53 AM
> To: llvm-dev at lists.llvm.org; 'cfe-dev at lists.llvm.org'
> Subject: [EXTERNAL] Re: [llvm-dev] Is there precedent for customizing clang -help output in a toolchain specific way
> 
> [+ cfe-dev]
> 
> Hi Todd,
> 
> We're currently trying to solve a similar problem for Flang [1]. From
> what we have seen so far,
> 
> * Options.td
> * the only instance of DriverOptTable [2]
> * the ID enum from clang/include/clang/Driver/Options.h [3]
> 
> are tightly coupled together and hence it is tricky to pick and choose
> what you want.
> 
> There's also getIncludeExcludeOptionFlagMasks in
> clang/lib/Driver/Driver.cpp [4], but I'm confused about the meaning of
> IncludedFlagsBitmask and ExcludedFlagsBitmask. We did experiment with
> that, but that made libclangDriver quite unhappy (things started to
> break in an unexpected way).
> 
> Perhaps somebody on cfe-dev (CC'ed) would have some hints? In the
> meantime we've also been customising Driver::PrintHelp().
> 
> -Andrzej
> 
> 
> [1] http://lists.llvm.org/pipermail/llvm-dev/2020-June/141994.html
> [2]
> https://github.com/llvm/llvm-project/blob/2c1799f8928e1a63020fa8099d254c084f8be2f2/clang/lib/Driver/DriverOptions.cpp#L43
> [3]
> https://github.com/llvm/llvm-project/blob/2c1799f8928e1a63020fa8099d254c084f8be2f2/clang/include/clang/Driver/Options.h#L39
> [4]
> https://github.com/llvm/llvm-project/blob/2c1799f8928e1a63020fa8099d254c084f8be2f2/clang/include/clang/Driver/Options.h#L26
> 
> 
> On 24/07/2020 20:36, Snider, Todd via llvm-dev wrote:
>> Hi All,
>>
>> I am looking to customize the -help display for a downstream clang port
>> as many options defined in Options.td are not applicable to the
>> processor family I�m targeting and several applicable options do not
>> have HelpText.
>>
>> I�ve considered adding a toolchain specific hook in the vicinity of
>> Driver::PrintHelp(), but I�d rather avoid adding a hook if there is a
>> better solution that already exists.
>>
>> Is there a best practice for enabling a toolchain to control the output
>> of the clang �help option?
>>
>> ~ Todd Snider
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>