epmikida
commented
5 years ago Original date: 2016-06-10 18:22:57
Here is the relevant bits of a Slack conversation about this topic:
Eric Mikida: is it possible to run charmc on a ci file and specifiy the path where we want the decl and defs to be put?
Phil Miller [11:02 AM] It writes the output in the current working directory. The easy way to get that effect would essentially be to run it in the desired output directory with a full or relative path to the input source
It also has options for output direction and copying. It could be adapted to understand -o or whatever with .ci file input to mean the place it should write those files
I don’t think those options would currently do anything for .ci file processing though
Eric Mikida [11:04 AM] they dont. i tried I'm just trying to figure out the best way to get charm to play nice with CMake. Switching directories before compiling ci files seems like the best bet for now, thanks.
Phil Miller [11:05 AM] This sounds like something we ought to fix in charmc itself, to make future use of CMake easier
It would be very helpful if you could write up a spec or brief description of how CMake would use it and what information it would have available, and stick that in a Redmine issue
I think we ought to just modify it to take -o and do the right thing
Though with multiple output files for each input, that gets a tad sloppy
Could you copy this conversation into said new issue, and we can continue it ‘on record'
?
Eric Mikida [11:07 AM] sure.
Phil Miller [11:07 AM] Star this message Thanks
Sam White [11:14 AM] Star this message You might want to take a look at Jozsef Bakosi’s quinoa project, which seems to use CMake and Charm++: https://github.com/quinoacomputing/quinoa
stwhite91
PhilMiller
evan-charmworks
Original issue: https://charm.cs.illinois.edu/redmine/issues/1098
It would be useful for CMake to be able to better handle Charm++ programs. Some of the issue comes from CMake's side, but there are things we could probably do in Charm++ to make things easier.
CMake has no problem recognizing ".C" as a C++ file, so changing the CMAKE_CXX_COMPILER to charmc for the whole project will get all regular source files compiling mostly without issue. I say mostly because if you are working in an existing project that uses stricter warnings, the compilation of the Charm stuff will likely make it fall over. Luckily you can set the flags of individual files, so I was able to sidestep this by adding the -Wno-error flag to the ".C" files I wanted to compile, while keeping the strict warnings for the rest of the project. If Charm begins to see more commercial use though we may want to at least try to cut down on the huge list of warnings we see every time we compile.
The trickier part in getting Charm++ to work with CMake is .ci files. CMake does not recognize .ci files so you have to manually add rules to get compilation working nicely. For a project I'm working on I came up with the following in my CMakeLists.txt:
file(GLOB CHARMSOURCES charm/*.C )
file(GLOB CISOURCES charm/*ci )
add_executable(exe ${SOURCES} ${CHARMHEADERS} ${CHARMSOURCES})
Unfortunately with the above code, the decl and defs are not put in the correct place and charmc does not allow -o when compiling ci files, so the command will have to change to call charmc from within the src directory. It may be helpful for future users to work out some of these kinks on our end, and also add some documentation for the best ways to handle Charm++ in CMake so people don't have to re-invent this or something similar every time they want to use CMake and Charm++.