This is excellent feedback. Thank you so much!
On Wed, Jun 25, 2025 at 8:17 PM Ryan Carsten Schmidt <[email protected]> wrote: > 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. > >
