Description
Per https://svn.open-mpi.org/trac/ompi/ticket/3211, we've gotten in kind of an ugly hole with the clang compiler: it allows passing "-Xclang " flags repeatedly, and at least one project does it (Homebrew). However, we currently use OPAL_UNIQ to remove repeated flags in various xFLAGS variables (CFLAGS, LDFLAGS, ...etc.). This obvious hoses the clang/Homebrew folks.
We fixed this in https://svn.open-mpi.org/trac/ompi/ticket/3211 by putting an exception for -Xclang. Ick.
This raises the question: why are we OPAL_UNIQ'ing at all? It seems like a bad idea to begin with.
In fairness, I think we started doing this because the .m4's distributed around our tree may have been accidentally adding the same flags to xFLAGS multiple times. And OPAL_UNIQ was a way to reduce the clutter.
A better approach might be not allowing adding new flags to xFLAGS that are already there (i.e., implicitly allowing "duplicates" only if the user set them via "./configure CFLAGS="-Xclang foo -Xclang bar"", or somesuch). This would effectively mean something like:
# Don't allow these
xFLAGS="$xFLAGS $my_new_flags"
# But rather force the use of this
OPAL_APPEND_UNIQ(xFLAGS, $my_new_flags)
Another approach may be to treat user-passed xFLAGS separately from OPAL/ORTE/OMPI-generated xFLAGS. We can then still OPAL_UNIQ-ize OPAL/ORTE/OMPI flags, but always pass through user-passed xFLAGS unscathed.
This has the advantage of not banning / hunting down and replacing the popular "xFLAGS="$xFLAGS $my_new_flags"" pattern from all throughout our .m4 files.
Two issues with this approach:
- We might end up duplicating flags between OPAL/ORTE/OMPI flags and user flags.
- It could get a little tricky to implement this in bourne shell (i.e., look for a subset of xFLAGS that was originally passed in from the user, strip them out, run OPAL_UNIQ on the remaining flags, and then put the user flags back in the middle / wherever they were in the string)