Practical way to combine conflicting options - algorithm

Question

I have a script which accepts multiple options as arguments. The list of valid options may be large (>20) which could result with conflicts. Is there a practical way to combine the conflicted ones together, and non-conflicted into another without creating multiple lists, groups, etc. Changes to one group will result in changes to other groups.
For example, the list of available options:-a, -b, -c, -d
The following options conflict: [-a, -c], [-a, -d]
The following options don't conflict: [-a, -b], [-c, -d]
EDIT, A more precise example:
For example, the script allows to start/stop a specific task and has additional options for creating/deleting logs.
A normal start would look like :
./script -start Task -logFile C:\out.tmp
And the script should notify the user in case something like:
./script -start Task -stop Task is executed, since start and stop are two opposite actions.
Another conflicting action:
./sript -start Task -logFile C:\out.tmp -deleteLog C:\out.tmp , which would create a log file and delete it at the same time
Now, if the options are start, stop, logFile, deleteLog,
The following would be conflicting: [start, stop], [logFile, deleteLog]
The following would not be conflicting: [start, logFile], [stop, deleteLog]

Answer 1

Let us assume that, as you are writing the source, you can decide how to organize your arguments for parsing time. For example (using JSON notation, you can easily adapt this to C structs, Java enums or what-have-you), you can annotate the available options to explicitly indicate which of them conflict:
const options = [
{
name: "start",
description: "starts foobaring the fizzbuzz",
parameters: [
{
name: "task",
type: "string",
optional: false,
description: "the type of task to foobar"
}
]
conflicts: ["stop"] // <-- explicit simple conflict detection
},
{ ... }
]
This would be used by a command-line parsing module to
generate a nice help screen, possibly including conflicting options
return a map of command-line options, say parsedArgs, so that parsedArgs['start'] would correspond to the parameters of the start parameter if it was specified.
detect simple conflicts, by complaining if conflicting options are detected at parse-time.
Note that there may be additional conflicts that it may not be worthwhile to detect at the parsing stage. For instance, if the value of option foo must be larger than bar + baz, it is better to code a check for this fact after parsing, rather than complicating the parser to handle arbitrary relationships between option values.