[llvm-cgdata] Remove GENERATE_DRIVER option

[petrhosek]

This tool shouldn't be used in the driver build until it is converted to
use OptTable for option parsing, otherwise the cl::opt options might
conflict with options in other tools resulting in link failures.

This is a reland of #100066.

[kyulee-com]

@petrhosek Thanks for attempting to fix this!
@gulfemsavrun I saw the original change + forwarding fixes were reverted by 73d7897
Is there any fundamental issue with this approach?

I understand the motivation behind using OptTable, but I am unsure of how to implement and test it as I have not encountered this failure in my environment. Additionally, I feel that using OptTable has a bit more abstraction compared to using cl, and I am not sure if it is fully expressible for the current usage. Is there any documentation available on this? I have mostly tried to mimic llvm-profdata or llvm-profgen, which do not use OptTable. It would be helpful to see some examples of handling similar cases.

[nico]

Here's an example of switching a tool to Opt: https://reviews.llvm.org/D100433 It links to another example, and there are many others.

Using Opt is fairly easy, give it a try :)

[petrhosek]

No longer needed since #89884 was reverted.

[kyulee-com]

Here's an example of switching a tool to Opt: https://reviews.llvm.org/D100433 It links to another example, and there are many others.

Using Opt is fairly easy, give it a try :)

@nico Thanks for the suggestion!
It appears that Opt requires a prefix like - or --. However, I would prefer to use a subcommand without a prefix, similar to llvm-profdata merge {some additional options + inputs}. I am curious if Opt offers such a feature that I may have overlooked. Alternatively, I can use a prefix for subcommands in the same way as additional options, but this would require adding checks for compatibility, which seems less than ideal
cc. @ellishg

[ellishg]

Is there any discussion or docs about Opt vs cl? Are there plans to deprecate cl in the future? For a simple tool like this, I appreciate the simplicity of cl since all the code lives in one file and subcommands are handled really well.

If we must use Opt, maybe we can first detect the subcommand and parse the tool different depending on that subcommand. This might require duplicate code for options that are shared between subcommands.

[nico]

@MaskRay might know if Opt has built-in subcommand support.

IIRC there were RFCs about moving from cl:: to Opt and there was general support. @MaskRay probably knows more about that too :)

[MaskRay]

Is there any discussion or docs about Opt vs cl? Are there plans to deprecate cl in the future? For a simple tool like this, I appreciate the simplicity of cl since all the code lives in one file and subcommands are handled really well.

If we must use Opt, maybe we can first detect the subcommand and parse the tool different depending on that subcommand. This might require duplicate code for options that are shared between subcommands.

cl::opt has some unusual option parsing behaviors, which make it not ideal as a user-facing tool. https://lists.llvm.org/pipermail/llvm-dev/2021-July/151622.html
https://reviews.llvm.org/D105532 and similar patches have migrated LLVM binary utilities to use OptTable, which avoids these problems.