<p>A more user-friendly way of dealing with this would actually be the opposite, i.e. making the use of the priority keyword conditional at preprocessing, based on the detected OpenMP version (which is trivial to do as shown in the patch) because as you say, all that the keyword really does is it improves load balance a tiny little bit in specific circumstances, but its absence has no effect on the correctness of the code. We could even avoid doing a <code>qsort()</code> on the package list as part of that conditional.</p>
<p>The less code is covered by conditionals the better.</p>
<p>Another option would be to specifically test for priority support in OpenMP, and just do something like this in pack.c:</p>
<p>Sometimes it's better to test for specifics features, sometimes for versions. I don't know how the OpenMP landscape looks like, but sometimes implementations only support a subset of a newer standard in which case testing for specific features is the friendlier way. OTOH the simplicity of being able to say "we require version X of standard Z" can be a bliss - for example we generally require POSIX.1 >= 2001 and that makes it fairly easy to cross-check portability issues and to say "no" to obscure stuff that doesn't fulfil that basic premist.</p>
<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />You are receiving this because you are subscribed to this thread.<br />Reply to this email directly, <a href="https://github.com/rpm-software-management/rpm/pull/1325#issuecomment-670372444">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/ADLPZU3JQJJZRZI6MFJWQTLR7OT5XANCNFSM4PVPF73A">unsubscribe</a>.<img src="https://github.com/notifications/beacon/ADLPZU3VWDU7LFUUGB2ZZWDR7OT5XA5CNFSM4PVPF73KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOE72REXA.gif" height="1" width="1" alt="" /></p>
"name": "View Pull Request"
"description": "View this Pull Request on GitHub",