Closed forrestglines closed 2 years ago
forrestglines
commented
3 years ago As a note, I did remove the generated auto_config.def header file from my build, and all references to it in src/Cell/monitor_Monitor.cpp. I don't think that it's causing issues.
mabruzzo
commented
3 years ago I spent some time looking at this today. I've got to cut my losses for now, but I wanted to share what I did (in case it helps). Maybe I can take another look tomorrow afternoon or Thursday.
First, I managed to replicate your issue using a netlrts-linux-x86_64 build of charm++
My best guess is that the issue relates to the inclusion of the following files when compiling cello_library:
${CMAKE_CURRENT_SOURCE_DIR}/Cello/main.cpp ${CMAKE_CURRENT_SOURCE_DIR}/Cello/main_enzo.cpp ${CMAKE_CURRENT_SOURCE_DIR}/Cello/main_mesh.cpp ${CMAKE_CURRENT_SOURCE_DIR}/Cello/main_simulation.cpp If you look at lines 194-202 from
src/Cello/SConscript, only some of these are included while compiling constituent libraries. But I'm not super confident in that assessment
While messing around with this I tried replacing the section of src/Cello/CMakeLists.txt related to the Cello layer with instructions that more closely reflected the instructions in src/Cello/SConscript. Basically, I went and tried to compile each of the individual libraries that we currently build. I did this so that I could try to compile some of the unit tests to see if I could get those to work (I thought that they might be easier to compile than the full Enzo-E binary). This turned out to be more work than I though, but I ultimately had some success. I was able to get some of the lightest-weight tests to run (and pass) like test_Error.cpp, test_memory.cpp, and test_monitor.cpp. I also attempted 3 other tests but those all failed (I think those are all linker errors)
I'm not sure how helpful this will be, but here is a copy of my src/CMakeLists.txt file. This is a little hacky/messy, but it should be readable. I wrote this by hand, so things are probably not perfectly transcribed (which is probably causing the linker errors - note that a bug is also preventing the Enzo-E binary from compiling). In hindsight, it would probably have been better to inject some code into src/Cello/SConscript to directly generate a CMakeLists.txt file. In the event that you do want to try to use this file, I think you may to know that I tweaked the root level CMakeLists.txt to include the following 2 lines:
set(HDF5_USE_STATIC_LIBS OFF) find_package(HDF5)
and I removed "hdf5" from "ENZO_E_LIBRARIES"
forrestglines
commented
3 years ago Thanks @mabruzzo! Compiling Kokkos with SConstruct turned out to be easier than I thought, so for now I'm abandoning my cmake attempt. I might return to this later though.
jwise77
commented
2 years ago This was addressed by #139
In preparation for incorporating Kokkos into Enzo-E, I need to get Enzo-E compiling and running with a build system that is compatible with Kokkos - either
cmakeor plainMakefile.cmakeshould be more flexible.I've started a branch here on my fork of Enzo-E for building Enzo-E with
cmake. However, it's currently not working, even with acharm++build that works fine with the masterSConsbuilt Enzo-E repo.From a high level, my cmake does these things to successfully compile Enzo-E (although the executable is broken).
libexternal_library.afrom all the Source and header files insrc/Externalusingg++*.decl.hand*.def.hheaders from all the*.cifiles insrc/usingcharmclibcello_library.afrom most of the source and header files insrc/Cellousingg++/gcc/gfortransrc/Enzousingg++/gcc/gfortranlibexternal_library.a,libcello_library.a, and the source files fromsrc/Enzotogether into an executable usingcharmc, also linking withdl, pthread, z, hdf5, png, gfortran, boostHowever, the resulting executable still doesn't work
Any suggestions for the
cmakebuild process? You can look at my repo andcmakebuild instructions at https://github.com/forrestglines/enzo-e/tree/cmake