Ticket 14873

Summary: Migration to c++ and cmake
Product: Slurm Reporter: Cristian Le <slurm>
Component: OtherAssignee: Jacob Jenson <jacob>
Status: RESOLVED INVALID QA Contact:
Severity: 6 - No support contract    
Priority: ---    
Version: 23.02.x   
Hardware: Linux   
OS: Linux   
Site: -Other- Alineos Sites: ---
Atos/Eviden Sites: --- Confidential Site: ---
Coreweave sites: --- Cray Sites: ---
DS9 clusters: --- HPCnow Sites: ---
HPE Sites: --- IBM Sites: ---
NOAA SIte: --- OCF Sites: ---
Recursion Pharma Sites: --- SFW Sites: ---
SNIC sites: --- Linux Distro: ---
Machine Name: CLE Version:
Version Fixed: Target Release: ---
DevPrio: --- Emory-Cloud Sites: ---

Description Cristian Le 2022-08-31 21:25:40 MDT
I am new to the slurm source code so I don't know the intrinsic reasons for using the plain C and make, but looking at the code, I see many places such as in `xstring.c` where there are just patches to the plain C language to make sure strings are safely operated on. But C++ already handles all of that more cleanly.

The reason I am asking about this is because the self-written apis are a barrier for new contributors having to shift through what stuff like `xstrfmtcat` is, where it is defined etc. C++ standards are well documented and any modern IDE will considerably help with suggestions. The latter part is also why I am asking about cmake, since the current build environment is not easily parsed by some IDES, CLion for example.

A migration to C++ and Cmake can be gradual, e.g.:
1. Create a basic cmake that reproduces the current make and configure build steps using the same source code
2. Gradually replace helper functions. This should not affect the API availability just the code implementation
3. Upgrade the slurm API to C++ (using namespaces/classes/etc.). Offer both C and C++ APIs where the C version calls the C++ implementations