Feature cmake migration

[JorySchossau]

This is an overhaul of the MABE build process to streamline the build, add better and more flexible support for project files, add support for linking arbitrary libraries, and also remove python as a build system dependency because so many people had issues with it. This also adds a new mbuild interface (which has its own repo). Now modules are actually modular and simply moving their folders into and out of MABE is all that is required to build with them, despite any special dependencies they may have.

Overview of changes:

• minimum required c++17
• moved all MABE source files into code/ dir
• moved pythonTools to tools/
• removed pythonTools/mbuild.py and all accompanying python utilities unique to mbuild
• temporary build files and project files now created in build/ dir
• final mabe executable now compiled to work/ dir where one should do their work
• .gitignore updated to ignore build/ and work/ so you can continue to push and pull while doing work
• Every module must now have a CMakeLists.txt file registering it with the build system, and defining how it is built and any software it relies on. See src/Utilities/Templates/CMakeLists.txt for a number of use case examples.
• buildOptions.txt renamed to modules.txt
• modules.h renamed and split into module_factories.h module_factories.cpp to fix the long-standing circular reference issue preventing certain module construction.
• CMake now generates module_factories.* and Utilities/gitversion.h that were previously generated by python.
• All builds now use all cores available by default, even if all you have is the Visual Studio compiler
• single setup.cmd script you can run on windows, mac, or linux, that puts mbuild in the root MABE dir for you.
• mbuild tool rewritten in Nim with the following new features:
  • binaries run on any distribution (linux, mac, windows) so no python needed
  • better streamlined experience (run mbuild, get mabe.exe)
  • ability to use an alternative arbitrary c++ compiler (cuda, pgi, openmp, etc.)
  • automatically keeps modules.txt up-to-date
  • create new modules like Brains and Worlds, installed and renamed for you
  • create new modules as copy of another module, installed and renamed for you
  • list, download, and install new modules from MABE_extras
  • generate IDE project files using CMake, which allows for more projects and better project features

The minimum workflow to get a compiled MABE, on Windows for instance, is now:

• Install Visual Studio and CMake
• Download and unzip MABE repo
• terminal to MABE
• tools/setup.cmd
• mbuild.exe

This also supports MSYS2 with gcc or clang on windows as before (I can't install the new MS Terminal, so I can't test that, but it should be fine). On MSYS2 it will default to using GCC, then Clang, then Visual Studio in that order of availability, unless you force it to use a particular one.

Known Issues:

• MarkovBrain and ANNBrain have "using namespace std;" that is breaking on Windows with Visual Studio. Should be fixed soon.
• None of the MABE_extras have been updated yet to be compatible with the CMake build system, but it should be fairly trivial to do so.
• Continuous Integration (automatic build checks) are obviously failing. They have to be updated to know about the new build system.

[JorySchossau]

After merge of setAllInputs feature, I'll need to rebase again to fix conflicts. Just an FYI if you're reviewing this.

[JorySchossau]

@Shalmezad We'd appreciate any comments if you're still working with MABE these days and have time to try this out.

[Shalmezad]

Will have to dig a bit deeper later. In particular want to try out the new mbuild items. The instructions you provided worked fine. Only issue I have right now is having the executables (lin_build, osx_build, and win_build.exe) in src/ as it's very easy to open them by accident when going through the source code. Would probably be best to move them to a separate directory (tools/ perhaps?)

[JorySchossau]

The instructions you provided worked fine.

Glad to hear it.

Only issue I have right now is having the executables (lin_build, osx_build, and win_build.exe) in src/ as it's very easy to open them by accident when going through the source code. Would probably be best to move them to a separate directory (tools/ perhaps?)

Good point. Will brainstorm given we also have a pytools dir. Thanks.

[JorySchossau]

• src/ moved to code/ (all scripts & build tools updated)
• pytools/ moved to tools/
• setup.cmd moved to tools/
• mbuild binaries moved from src/Utilities/ to tools/
• updated all mbuild binaries to fix a bug and some help message details

[cliff-bohm]

A quick note on sh setup.cmd if there is a space (' ') in the pathname, sh setup.cmd fails to find the destination folder.

[JorySchossau]

A quick note on sh setup.cmd if there is a space (' ') in the pathname, sh setup.cmd fails to find the destination folder.

Thanks! Fixed in b41a801a74d5231b4dd1648df69ef7d6aa6e9c0c

[JorySchossau]

Warning of missing modules.txt should be more concise.

[JorySchossau]

Executable permissions are missing if repo is copied between operating systems. We should add a chmod into the setup script.