Our compilation options structure supports appending arbitrary extra options. However, those options could potentially conflict, or repeat, options we set through the fields of the compilation_options_t structure; and CUDA's NVRTC can be rarther touchy about such cases.
We should offer the library user the ability to resolve these situations, i.e.:
Remove extra options which will be generated anyway on the command-line to due to non-extra option values.
Do something intelligent if an extran option conflicts with a non-extra-option field value: Throw an exception or use the extra option as an override (i.e. set the non-extra option)
I mulling over whether to split this bug into two, one for duplicate removal and one for conflict resolution; but since the code for both would probably be in the same place, let's keep it one bug for now.
Note that override application essentially requires full option parsing, while for the rest it is sufficient if we are able to render individual option values to strings. Regarding option parsing, see also #692 .
Our compilation options structure supports appending arbitrary extra options. However, those options could potentially conflict, or repeat, options we set through the fields of the compilation_options_t structure; and CUDA's NVRTC can be rarther touchy about such cases.
We should offer the library user the ability to resolve these situations, i.e.:
I mulling over whether to split this bug into two, one for duplicate removal and one for conflict resolution; but since the code for both would probably be in the same place, let's keep it one bug for now.
Note that override application essentially requires full option parsing, while for the rest it is sufficient if we are able to render individual option values to strings. Regarding option parsing, see also #692 .