[llvm-dev] Is there precedent for customizing clang -help output in a toolchain specific way
Andrzej Warzynski via llvm-dev
llvm-dev at lists.llvm.org
Thu Aug 6 12:44:21 PDT 2020
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
. 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.
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 . From
> what we have seen so far,
> * Options.td
> * the only instance of DriverOptTable 
> * the ID enum from clang/include/clang/Driver/Options.h 
> 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 , 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().
>  http://lists.llvm.org/pipermail/llvm-dev/2020-June/141994.html
> 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
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
More information about the llvm-dev