[Scons-users] SCons popularity

Kenny, Jason L jason.l.kenny at intel.com
Thu Jun 4 14:20:58 EDT 2015


Well said!

There is a lot of good stuff to say about SCons ( and I would like to add Parts) and there is stuff to improve. But on simple message I would have to say is that for a projects that I have worked on that use to have 5 people to support the build for one product, the move to SCons allowed the team to have 1 person support 3 products. ( no kidding) which allows everyone to work on the important stuff. This is a common theme I have seen. The cost of a build system can be very high! SCons has always reduced that cost. (And I would like to think Parts help with that as well  :-) )

Jason

-----Original Message-----
From: Scons-users [mailto:scons-users-bounces at scons.org] On Behalf Of Damien
Sent: Thursday, June 4, 2015 12:44 PM
To: SCons users mailing list
Subject: Re: [Scons-users] SCons popularity

Further to what Jason has said (snipped for brevity), the Gentoo and Debian articles are narrowly focused on what they want for their distribution of Linux.  SCons might not be the ideal tool for Linux distribution-specific packages, but who cares?  The underlying argument often seems to be "SCons isn't a better implementation of autotools and make, so it's bad."  That's not what SCons is for.

If you're developing cross-platform, cross-hardware, software, you're possibly signing up for different CPUs, different OS versions, different compiler and different run-time versions.  This is not for wimps, but if you want to do cross-platform software, you want to use a cross-platform build system.  There's a *lot* of ground you might have to cover:  
Microsoft has three major compiler versions in the wild right now, VS2010, VS2012 and VS2013.  VS2015 is around the corner (I'm ignoring older VS editions that are still used).  Win 7, 8, 8.1 and shortly 10, plus Server 2008 versions onwards.  There's what, at least five different Linux distributions that make up most of the OSS Posix market?  Active GCC versions from 4.4 onwards up to 5.1.  The OSX walled garden is easier but it's still different.  Intel supplies compilers for all of those platforms too, with a few current versions.  That's just software, and doesn't cover the big commercial Unixes.  X86/X64, Arm, Power, ATI and Nvidia GPU hardware too.

Cross-platform software is a lot more work.  It just is.  You have to invest the same quality of engineering into your cross-platform build system as you do in your cross-platform software if you want to get it right.  Note I said quality, not quantity.  We found that after a considerable amount of initial pain, our SCons build system doesn't change much.  New scripts, some new directories, and it just works, which means we spend more time on software and almost none on "why isn't the left handed soy-bean two-pump vanilla frappacino toolset not building?"  We're about to start 32-bit Linux-ARM development and because of SCons I suspect it will take only a couple of hours to set up the build environment, and not one SConscript in the entire codebase will have to change.

Write your own installers using SConscripts, and make them configurable.  If you're going open-source, supply the whole build setup as part of the package.  You have to do that anyway for Windows and OSX because your software isn't distributed by MS and Apple and they don't care what you do.  I personally believe that's a better model and more responsible, you should know how to make your software build and run on whatever you ship for.  You shouldn't offload that to distribution devs.

If you want to do cross-platform software, I'd recommend SCons. Yes, it's slower than some more specific alternatives.  But it's consistent, flexible and reliable, and for cross-platform you have to have that so you can work on your software and not on your build system.

Cheers,

Damien
_______________________________________________
Scons-users mailing list
Scons-users at scons.org
https://pairlist4.pair.net/mailman/listinfo/scons-users


More information about the Scons-users mailing list