This is all @joa-quim I think. I really want us to standardize on OpenMP as having too many different system for achieving the same thing makes maintenance much harder and add more dependencies for just a few modules. I have added OpenMP to several modules and library functions and if I find time (hah!) I would like to rewrite grdfilter to use OpenMP, etc., etc.

But to answer your question, yes, I guess glib2 (at least for now - see above) should be treated the same way we treat other optional libs like Lapack, etc.

OK. I will submit a PR for glib2 later.

As for OpenMP, we still need to figure out how to enable OpenMP on macOS using Apple's default compiler.

Apple has yet to implement OpenMP in their clang. once can install another version or use gcc to build it. Just install gcc and make a file (here cache.cmake):

SET ( CMAKE_C_COMPILER "/opt/local/bin/gcc-mp-9" CACHE STRING "GNU MP C compiler" )
SET ( CMAKE_CXX_COMPILER "/opt/local/bin/g++-mp-9" CACHE STRING "GNU MP C++ compiler" )
SET (CMAKE_C_FLAGS -flax-vector-conversions)
SET (CMAKE_C_FLAGS_DEBUG -flax-vector-conversions)
SET (CMAKE_C_FLAGS_RELEASE -flax-vector-conversions)
SET (OpenMP_C_FLAGS -flax-vector-conversions)

and then

cmake -DCMAKE_INSTALL_PREFIX=gmt6 -DCMAKE_BUILD_TYPE=Release -G Ninja -C ~/cache.cmake ..

pthread is not used anywhere in GMT, but we build a test using it (pthreads_example)

Apple has yet to implement OpenMP in their clang.

I think that's not true. I can use OpenMP with AppleClang, following this post (https://iscinumpy.gitlab.io/post/omp-on-high-sierra/), so it's doable. The only problem is cmake can't find AppleClang's OpenMP support correctly.

pthread is not used anywhere in GMT, but we build a test using it (pthreads_example)

Since it's never used, do you think we should remove it?

Yes, I think we should. Afaik, it was Florian that for some reason added that pthread test.

Regarding OpenMP the VS support is lousy but found this, which makes think things are changing. The #pragma omp for simd seems really interesting.

But reading this https://developercommunity.visualstudio.com/idea/351554/please-support-newer-version-of-openmp.html chills out the enthusiasm. The VS guys talk about OMP is just hard to believe they are talking seriously.

I think that's not true. I can use OpenMP with AppleClang, following this post (https://iscinumpy.gitlab.io/post/omp-on-high-sierra/), so it's doable. The only problem is cmake can't find AppleClang's OpenMP support correctly.

I could actually let CMake found OpenMP, using Homebrew's libomp.

Details are in the attached brew formula

$ brew install -vv ./gmt.rb

However compilation aborts at 42% with this error:

/tmp/gmt-20191102-74335-1w0o76o/gmt-6.0.0/src/grdlandmask.c:649:2: error: condition of OpenMP for loop must be a relational comparison ('<', '<=', '>', or '>=') of loop variable 'row'
        gmt_M_grd_loop (GMT, Grid, row, col, ij) {      /* Turn levels into mask values */
        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/tmp/gmt-20191102-74335-1w0o76o/gmt-6.0.0/src/gmt_grd.h:165:40: note: expanded from macro 'gmt_M_grd_loop'
#define gmt_M_grd_loop(C,G,row,col,ij) gmt_M_row_loop(C,G,row) gmt_M_col_loop(C,G,row,col,ij)
                                       ^~~~~~~~~~~~~~~~~~~~~~~
/tmp/gmt-20191102-74335-1w0o76o/gmt-6.0.0/src/gmt_grd.h:163:47: note: expanded from macro 'gmt_M_row_loop'
#define gmt_M_row_loop(C,G,row) for (row = 0; (int)row < (int)G->header->n_rows; row++)
                                              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.

So this works fine with gcc -fopen and clearly we are using rational comparison <. It must not like to expand the macro or the cast to signed int? (WIndows demands signed ints....)

I recently updated cmake to 3.16.2, and cmake now can find AppleClang OpenMP correctly. However, as reported by @claudiodsf, the compilation gives an error.

I am trying to ease back into OpenMP. Before I try Xcode, I wanted to just do gcc. This worked previously with gcc for me, but now I get tons of these

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/System/Library/Frameworks/Accelerate.framework/Frameworks/vecLib.framework/Headers/vBasicOps.h:379:70: error: incompatible type for argument 2 of '_mm_mullo_epi16'

despite having

set (CMAKE_C_FLAGS -flax-vector-conversions)
set (CMAKE_C_FLAGS_DEBUG -flax-vector-conversions)
set (CMAKE_C_FLAGS_RELEASE -flax-vector-conversions)

in my cache file. After config I see

-- Using CFLAGS = '-std=gnu99 -Wextra -Wall -Wdeclaration-after-statement -fopenmp -O3 -DNDEBUG'

so so much for the flax settings. Thought?

It seems you have to set all variables as cached entries.

SET ( CMAKE_C_COMPILER "/opt/local/bin/gcc-mp-9" CACHE STRING "GNU MP C compiler" )
SET ( CMAKE_CXX_COMPILER "/opt/local/bin/g++-mp-9" CACHE STRING "GNU MP C++ compiler" )
SET (CMAKE_C_FLAGS -flax-vector-conversions CACHE STRING "C FLAGS")
SET (CMAKE_C_FLAGS_DEBUG -flax-vector-conversions CACHE STRING "C FLAGS DEBUG")
SET (CMAKE_C_FLAGS_RELEASE -flax-vector-conversions CACHE STRING "C FLAGS RELEASE")
SET (OpenMP_C_FLAGS -flax-vector-conversions CACHE STRING "C FLAGS OPENMP")

Is this still an open issue?

Yes, we still have trouble enabling OpenMP on macOS.