Mac OS X Build error -fopenmp, used g++ instead of CMAKE_CXX_COMPILER about exatn HOT 9 CLOSED

It looks to me that making ExaTensor part of the CMAKE build will keep breaking and it takes way too much time to fix. Should we instead reconsider and require users to build ExaTENSOR or TAL-SH standalone as a prerequisite for ExaTN. Then, ExaTN can just link with libexatensor.so or libtalsh.so, but this will still require adding openmp and cuda libraries in the linking line. Currently I do not necessarily have a good idea how to fix the build system for good ...

from exatn.

I've always found it difficult to integrate projects with CMake build systems with projects with standard Make build systems. But I'm not convinced that we should wave the white flag yet. I think the issues we are having are more so growing pains. The improvements Joe has made have been a great step in the right direction, we just need to iron out the kinks. I'll spend some time on this tomorrow with Joe.

If this continues going on for another week or two, I will definitely be open to pulling ExaTensor out as its own separate, manual build dependency.

from exatn.

Thinking about this a bit more...

The cool thing about CppMicroServices is that it allows developers to operate in their own sandbox implementing specific interfaces (plugins) that are then contributed to some core framework via installation to a specified folder.

Since the only thing in ExaTN that requires ExaTensor/Talsh is the node_executors, we could consider pull ExaTensor out of ExaTN and instead just contribute a new ExaTensor folder that implements node_executors and exposes an Activator/etc in order to create a new node_executor plugin shared library that is installed to the correct plugins/ folder for exatn to see. I think this could all be done through the existing ExaTensor Makefile.

In this way, ExaTN only cares about its core interfaces, and subtypes can be provided as external, sandboxed implementations.

From a design perspective, I like this approach a lot.

So someone would clone exatn, run cmake, and make install. And then they would clone ExaTensor and run make with appropriate environment variables (plus a new one directing the build and install of new exatn node_executors).

from exatn.

Sounds like an interesting idea.

from exatn.

I think a better solution to resolve this issue is the following. I can easily make ExaTENSOR/TALSH import CMAKE_CXX_COMPILER, CMAKE_C_COMPILER, CMAKE_Fortran_COMPILER variables from the environment as long as they are set in the make line created by CMAKE for building ExaTENSOR/TALSH. Are they set there (or can we set them there)? Then I will just import these three (did I spell them right?).

from exatn.

They aren’t set as env vars right now but we could set it up that way. You spelled them right. Just have to update the make lines in tpls/CMakeLists.txt to replace CPP_GNU=${CMAKE_CXX_COMPILER} to CMAKE_CXX_COMPILER=${CMAKE_CXX_COMPILER}, and the others similarly

from exatn.

Ok, then I will go ahead and update ExaTENSOR/TALSH Makefiles to import these three variables when EXATN_SERVICE=YES. This mechanism will then work for any compiler suite, not just GNU.

from exatn.

Once you update the CMakeLists.txt, go ahead and merge it into devel. I've just merged devel_dil (including mccaskey/devel_dil) into devel. It builds fine with no MPI and ATLAS BLAS.

from exatn.

All ExaTENSOR/TALSH Makefiles will now import CMAKE_{C,CXX,Fortran}_COMPILER from CMAKE when EXATN_SERVICE=YES. Pushed to ExaTENSOR master branch. We need to move the ExaTENSOR submodule head to the top of the ExaTENSOR master branch.

from exatn.