I've been a MacPorts manager for 16 years, have maintained the scons port for 8 years, and have dealt with many ports that use the scons build system.
I don't like scons. I have recently submitted a cmake build system to a project to replace their scons build system. Two major design problems with scons, in my opinion, are ignoring environment variables and requiring you to write scripts in python. The writer of each SConscript or SConstruct file is responsible for knowing which environment variables users are likely to expect their build system to honor, and many writers of those scripts are not aware that that is their responsibility and don't do so. When I am trying to build a project with scons, it often won't be able to find its dependencies, because the developer did not think to explicitly import the PATH environment variable. I then have to patch their build system. Additional environment variables that are of importance on macOS include DEVELOPER_DIR and MACOSX_DEPLOYMENT_TARGET. Our serf1 port currently contains patches to honor PATH and DEVELOPER_DIR and a different workaround to honor MACOSX_DEPLOYMENT_TARGET. The problem with being based on python is that you're subject to changes in the python language over time. We had lots of problems when we switched the scons port from python 2 to 3. The syntax of the print statement changed, as did many other things. scons itself was fine with it by then but not every project that used scons was; some were old projects that hadn't released new versions in a long time. It took for us time to identify which projects were not compatible with python 3 and to update their code. This has continued as we have upgraded to newer versions of python 3 and python features that old scons projects relied upon change or are removed. setuptools/distutils is an example. See https://trac.macports.org/ticket/72354. As long as the developers who use scons in their projects are aware of these issues, and manually import important environment variables and stay on top of changes in the python language and timely release new versions of their software to deal with them, scons can be fine. But other build systems take care of environment variables for you and don't tie you to the whims of an external scripting language. And cmake is more popular and therefore better, to put it bluntly. When I encounter a problem with a project using cmake, it's easy to find a solution, because so many people are using cmake and documenting problems and solutions. With scons it is more difficult and thus more frustrating, as has been mentioned before in this thread. I feel that cmake is also better about maintaining backward compatibility than is the python language which is important when you want to build old software.
