Driver options taking a value typically use `=` as the separator, instead of a space. Not using a space also helps a dozen compiler driver wrappers which don't want to know which options are `Separate`. Unfortunately many older driver options do not stick with the rule, but I find -Xclang used a lot and will provide convenience when -Xclang= is supported. For build systems using a string array instead of a string to indicate compiler options, `["-Xclang=-foo"]` is more convenient than `["-Xclang", "-foo"]`. Note: there is a `=` precedence for `-X*` option: `-Xopenmp-target=`.

Driver options taking a value typically use `=` as the separator, instead of a space. Not using a space also helps a dozen compiler driver wrappers which don't want to know which options are `Separate`. Unfortunately many older driver options do not stick with the rule, but I find -Xclang used a lot and will be convenient if -Xclang= exists. For build systems using a string array instead of a string to indicate compiler options, `["-Xclang=-foo"]` is more convenient than `["-Xclang", "-foo"]`. Note: there is a `=` precedence for `-X*` option: `-Xopenmp-target=`.

Driver options taking a value typically use `=` as the separator, instead of a space. Not using a space also helps a dozen compiler driver wrappers which don't want to know which options are `Separate`. Unfortunately many older driver options do not stick with the rule, but I find -Xclang used a lot and will providbe convenience whent if -Xclang= is supportedexists. For build systems using a string array instead of a string to indicate compiler options, `["-Xclang=-foo"]` is more convenient than `["-Xclang", "-foo"]`. Note: there is a `=` precedence for `-X*` option: `-Xopenmp-target=`.