Evan Ramos

Passing `smp` as part of the build tuplet instead of as a separate word is silently accepted but does not actually build in SMP mode. For example, `./build AMPI mpi-linux-x86_64-smp...

Does reverting or cherry-picking ca4221e4a5c5f23ba820a90b23352cc85f854e5c affect `-c++-option`?

It looks like the CMake build system is creating metis objects directly in `src/libs/ck-libs/metis/` instead of the tuplet subfolder.

A remaining to-do item is Microsoft MPI support on Windows.

If I build with `-fsanitize=address`, linking the hello example fails because it lacks this argument (and presumably anything else on the build line).

I believe the i386 autobuilds are actually testing x86_64 because the platform parts of the build tuplet passed to buildcmake are not used when invoking cmake.

Some CIs print a warning that we set CMP0075 to OLD. ``` CMake Deprecation Warning at CMakeLists.txt:25 (cmake_policy): The OLD behavior for policy CMP0075 will be removed from a future...

Followup from #2990. Some issues were previously documented at the following link, and I'm repeating them here. https://github.com/UIUC-PPL/charm/pull/2990#issuecomment-673744857 > Our MPI Linux SMP build in particular appears to be buggy...

With this change, the example completes: ```diff $ git diff -U2 diff --git a/examples/charm++/refnum/test.C b/examples/charm++/refnum/test.C index 49d89b8f0..a099283fb 100644 --- a/examples/charm++/refnum/test.C +++ b/examples/charm++/refnum/test.C @@ -25,5 +25,5 @@ public: Array1() { iter...

Draft for now because this PR should probably also add documentation, and we may change the API further.