Inital support CMake build and Devcontainer configuration

[moschmdt]

@garfieldnate as discussed, this is the initial draft for CMake build without interfering with scons as far as possible.

This builds the soar library, excluding the SWIG interfaces and SVS, as well as the SoarCLI.
Additionally, the CMake build uses the conan package manager to fetch dependencies for all platforms, currently only SQLite3.

The only part where scons and CMake interfere is the following problem:
scons adds a file called build_time_date.h during the build process, which leads to failing builds for CMake. Is the build time still relevant that it should be behind a feature flag, is the feature rather deprecated and could be removed, or should this be replicated in CMake @garfieldnate?

[garfieldnate]

Wonderful, thank you very much!

Just to confirm, SWIG, SVS and SoarCLI are excluded not because they are impossible to build with CMake, but because they were not needed for the ROS2 package, correct?

I do think we need to generate the build_time_date.h file. I would also update it in the future to contain the commit SHA. I haven't tested this, but GPT suggested generation code that looks like this:

cmake_minimum_required(VERSION 3.16)
project(MyProject)

# ... other CMake code ...

# Get timestamp and Git SHA
string(TIMESTAMP CURRENT_TIMESTAMP "%Y-%m-%d %H:%M:%S")
execute_process(
  COMMAND git rev-parse HEAD
  WORKING_DIRECTORY ${CMAKE_SOURCE_DIR}
  OUTPUT_VARIABLE GIT_SHA
  OUTPUT_STRIP_TRAILING_WHITESPACE
  ERROR_QUIET
)

# Generate the version file
configure_file("${CMAKE_CURRENT_SOURCE_DIR}/build_time_date.h.in" "${CMAKE_CURRENT_BINARY_DIR}/build_time_date.h")

# Add the generated header file to the include directories
include_directories("${CMAKE_CURRENT_BINARY_DIR}")

I will not have time to review this until December, but I'm very grateful for the contribution and look forward to improving the build system.

[garfieldnate]

Haven't reviewed it yet, but I do have a question: does this support both the SCU and non-SCU versions of the build? Or if only one, which one? The non-SCU version is supposed to be easier to debug (see #500). I'm not sure what the advantage of the SCU version is; perhaps compile time?

[moschmdt]

Just to confirm, SWIG, SVS and SoarCLI are excluded not because they are impossible to build with CMake, but because they were not needed for the ROS2 package, correct?

SWIG

SWIG is not built with CMake right now, but should be possible according to swig_add_library(..) CMake.

SVS

Not built.

SoarCLI

Already built with CMake, cf. SoarCLI/CMakeLists.txt as a subproject.

Unit Tests

I got them built with CMake but this is not ready to merge, thus not included in this PR.

SCU and non-SCU versions of the build

For now, this supports only the builds based on the cxx files. As far as I can tell, this means SCU compilation, since there was no benefit to collecting all source files individually for me. The same applies to shared vs. static library. The PR only adds the static library build for now - could be extended without much additional effort later if needed, e.g. for SWIG or Python bindings. I did some debugging and never had any debugging problems with the CMake VS Code extensions.

[moschmdt]

I do think we need to generate the build_time_date.h file.

Is there any specific reason why it is not tracked via git and generated during build time? The following code is from the generated build_time_date.h file, but the __TIME__ and __DATE__ all already macros replaced during build time. This looks to me like that was from a time before those macros existed?
If there are no opposing arguments, we could just add the file to the git repo and the problem is fixed? No further CMake required and SCons checks if the file is available - so no change needed here.

const char *kTimestamp = __TIME__;
const char *kDatestamp = __DATE__;
//* Last build of Soar 9.6.3 occurred at Fri Nov 22 17:20:20 2024 *//

[moschmdt]

I just had a little time to work on the Unit Tests. Currently 384/394 test are completed successfully. Most of the failing tests are SVS related. @garfieldnate should I include it in this PR?

Last test output:

https://github.com/moschmdt/Soar/actions/runs/12046432023/job/33586895049#step:11:1