> 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
> `qsort()` on the package list as part of that conditional.
The less code is covered by conditionals the better.
Another option would be to specifically test for priority support in OpenMP,
and just do something like this in pack.c:
```
#ifndef HAVE_OMP_PRIORITY
#define priority(x)
#endif
```
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.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1325#issuecomment-670372444
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
