Improving the portability of EMOD

[kskyten]

I would like to make EMOD more compatible with other platforms and I'm trying to
figure out how the compilation of EMOD works. Could you explain how the logic
works? Also, which dependencies are needed for which part of EMOD?
Is python used outside of reporting?

Looking at the main SConscript file, there seems to be a section for building
shared libraries (DLLs), but as far as I understand the paths that it is
referring to do not exist (libgeneric/*). Is this directory built during the
compilation or is the code stale?

Ultimately, I would like to use CMake instead of Scons as the build manager for
better portability and possibly faster builds using Ninja.

[jonathanhhb]

Hello. Thanks for your interest in EMOD.

We definitely support the overall goal of cross-platform compatibility -- as resources allow. Right now EMOD builds on various flavors of linux in addition to the primary Windows platform.

SCons was actually chosen over CMake due to its being cross-platform.

Have you tried building with SCons yet? What platform are you on?

SCons uses python, so that's the first dependency. And our test harness is all python. You can build the EMOD executable with ENABLE_PYTHON which then enables you to write pre- and post-processing files in python, but that's an optional capability.

You shouldn't need to build DLLs at first.

The typical build scenario would be something like:
scons --Release --jobs=4

Though just "scons" should work. It then proceeds to compile all the files into a single binary Eradication (or Eradication.exe on Windows). It builds some static libraries along the way.

Does that help?

[kskyten]

I'm trying to package EMOD for the Nix package manager.
I get the following error when compiling the latest version on the master branch on NixOS:

In file included from utils/JsonFullReader.h:12:0,
                 from utils/JsonFullReader.cpp:11:
rapidjson/include/rapidjson/document.h: In instantiation of ‘rapidjson::GenericDocument<Encoding, Allocator>& rapidjson::GenericDocument<Encoding, Allocator>::ParseStream(Stream&) [with unsigned int parseFlags = 0; Stream = rapidjson::GenericStringStream<rapidjson::UTF8<> >; Encoding = rapidjson::UTF8<>; Allocator = rapidjson::MemoryPoolAllocator<>]’:
rapidjson/include/rapidjson/document.h:745:39:   required from ‘rapidjson::GenericDocument<Encoding, Allocator>& rapidjson::GenericDocument<Encoding, Allocator>::Parse(const Ch*) [with unsigned int parseFlags = 0; Encoding = rapidjson::UTF8<>; Allocator = rapidjson::MemoryPoolAllocator<>; rapidjson::GenericDocument<Encoding, Allocator>::Ch = char]’
utils/JsonFullReader.cpp:25:34:   required from here
rapidjson/include/rapidjson/document.h:710:25: error: invalid operands of types ‘<unresolved overloaded function type>’ and ‘unsigned int’ to binary ‘operator<’
         if (reader.Parse<parseFlags>(stream, *this)) {
             ~~~~~~~~~~~~^~~~~~~~~~~
scons: *** [build/x64/Release/utils/JsonFullReader.o] Error 1
scons: building terminated because of errors.

I have the following versions of software and libraries in the build environment:
gcc 7.3.0
Python 3.6.6
Boost 1.67
MPICH 3.2.1

What version of gcc are you using on the CentOS build?

[kskyten]

I tried to build the previous release (v2.13.0) and hit the same problem. It seems like this is a problem with the code instead of my setup. Although it is possible that I am missing some dependency or that my compiler treats the code differently. What can I do to debug this issue?

[jonathanhhb]

Yes, we have observed this issue when compiling rapidjson with the latest versions of GCC. There's a bit of an "upgrade cascade" to get around/fix that. We are using GCC 4.8.5 at this time.

[clorton]

Hi, as Jonathan mentioned, the version of rapidjson included with EMOD is a bit out of date (although quite functional) and doesn't work well with the latest versions of GCC. We have not yet assessed the difficulty of upgrading the version of rapidjson being used with EMOD.

[kskyten]

Thanks, I got it to compile with GCC 4.8.5.