Create CMake for 2Decomp

[af-ayala]

Currently 2Decomp uses many hard-coded variables during building process, which makes it not portable to other machines.
Using CMake instead of Makefile would certainly help very much.

[G-Ragghianti]

The current release of 2decomp provides only a makefile. Are you proposing to take over development of a cmake-based build system for 2decomp? This isn't necessary because we are going to be using a new spack package for the install of 2decomp. You can see it in my branch at https://github.com/icl-utk-edu/fiber/blob/gragghia/ci/spack/packages/2decomp-fft/package.py

The spack package will be able to modify any of the required configuration parameters for the build by just editing the Makefile.inc.

[luszczek]

2decomp is unmaintained. Providing CMakeLists.txt is a one-time task. And Spack can just build on that. That was my suggestion.

[G-Ragghianti]

I just wouldn't want to work on a cmake for a package that isn't mine. I suppose it depends on how much work it would take. For me it would take a lot of work because I have limited experience. What are the specific advantages of a cmake build that we can't do right now with spack's makefile editing? From looking at the Makefile.inc.x86 in 2decomp, it appears that we mainly just need to make sure it can link with the fft backend. The spack compiler wrapper should take care of that, or worst-case we have to pass it the INCLUDE and LIB directories.

[luszczek]

find_package(fftw3 REQUIRED) takes care of FFTW3 backend and Spack gives all details to CMake implicitly. I'd rather not be digging in Spack's spec object to put the info out. But that's just me. CMake will be informed directly about INC and LIB lists. Adding this things in Makefile.inc.x86 requires finding a string in the original and being clever about replacing it. I've done it a few times and the process is uninviting to say the least.

[G-Ragghianti]

Usually you can just do make LIB=<dir> INC=<dir> or similar to avoid editing the makefiles.inc, but I think that may not even be necessary if spack's compiler wrappers provide that automatically. I will test it with my current spack package (2decomp-fft) using fftw and MKL.

[luszczek]

Geri, it's up to you. We spent some time debugging Makefile, variables, and if-then-else logic inside of it. We eventually translated ORNL/OLCF variables into ICL/Saturn variables and the build succeeded. It was a chore to get through all the layers. If you can get Spack package working for 2decomp with mkl and fftw3 variants then we can work off of that.

[G-Ragghianti]

OK, I have added fftw and mkl support to the 2decomp-fft spack package. It is included in my currently open PR.

[cayrols]

Thank you Geri!
I will have a look soon.