Normalize locations of external libraries

[rbuch]

External libraries are scattered across the Charm++ codebase (e.g. nlohmann/json in src/util (not in a directory of its own), METIS in src/libs/ck-libs/metis, hwloc in contrib/hwloc, etc.). These should all be relocated to some common location (maybe contrib/?) so that it's clear what's an external library and what's not. Maybe they should even be submodules or use CMake's FetchContent or some other package manager.

[stwhite91]

We should first make a list of all external dependencies, then consolidate as many as possible to a single location such as contrib/. Some may be more tightly integrated into our codebase than others.

These are the ones that I know of:

src/QuickThreads/ src/conv-core/memory-gnu-internal.C <= dlmalloc contrib/hwloc/ src/libs/ck-libs/metis/ src/util/json{-fwd}.hpp <= nlohmann/json src/util/boost-context/ src/arch/util/lz4.{c,h} src/libs/ck-libs/ampi/romio/ tests/ampi/mpich-test/ src/libs/conv-libs/openmp_llvm/

Any others?

[evan-charmworks]

It's good to have these documented, and I see some room for improvement. At the same time, any reorganization more than a light touch would best be paired with an overall review of all files in the repository. For example, we renamed our default branch to main but check out what's in conv-libs.

We should look at other projects to see what nomenclature they use for these. contrib/ is the closest we have, but none of these are contributions per se. Something like imports/ or external/ might work.

Of these, dlmalloc, hwloc, nlohmann/json, boost-context, and lz4 are good candidates for moving. ROMIO and the MPICH tests are probably good where they are. The rest I am unsure about.

Maybe they should even be submodules or use CMake's FetchContent or some other package manager.

Strong disagree, submodules are a pain (I experimented when importing hwloc) and downloading stuff during the configure or build steps is IMO an anti-pattern.

[lvkale]

some of these are dependencies for Charm++ and others are on top of Charm++. We probably need to separate those. Some may have loose dependencies, like METIS. (But it looks like the ones list above are all dependencies for Charm++/ampi)