[Scons-users] SCons popularity

Fri Jun 5 00:59:38 EDT 2015

To whom it may concern,

It seems the majority of discussion against SCons in this forum is that
SCons doesn't behave like Make, and learning new things is hard: a harsh
paraphrase partly in sarcasm.

A lot of the complaints here are rather trivial:

   1. SCons doesn't use my shell environment
      1. SCons has a rule for repeatable builds; random shell environments
      do not provide said item, and this is one of the best parts of SCons.
      2. If you REALLY need said thing.  You can copy os.environ into the
      SCons environment object with 1-line of code if I remember correctly.
   2. Install is hard.
      1. As Jason already said, even in Make, Install is a convention.
      2. Writing Install code in SCons is easy and can be done with a few
      lines of code.
         1. I can run SCons install without compiling, and SCons will
         figure it out for me.
         2. With 1-2 more lines of code I can run unit tests with SCons
         from a clean repo, and SCons will guarantee all my code is up-to-date.
         F*cking A!
      3. SCons requires adding command-line options for stuff and things?
      1. I can specify environment variables like CCFLAGS on the
      command-line without adding code to my scripts.
      2. Linux packagers need to create wrappers: maybe but GNU autotools
      isn't really cross-platform, so it's easy to tailor to the needs of a few
      (arguably one).
      4. SCons isn't Make
      1. You are right; it isn't.  It will take a few minutes to learn
      because it has lots of cool features.
      1. Make has the advantage of history, but if you haven't used Make
         for 20 years, it is archaic and hard to learn.
         2. In all honesty, its amazing how many people won't or can't read
         the User's Guide.  Google that for you?
            1. I think this might be one of the biggest problems SCons
            faces. Make is a build tool.  SCons is build tool.  SCons
must work like
            Make. Silly right?
            2. SCons uses python rather than archaic scripting languages
      like M4 giving users a lot of power to make some great extensions.
      3. I've never used a flavor of Make or autoconf-like software that
      got build dependencies as automatically and correctly.

There are different tools for different problems.  SCons doesn't solve all
of them, but SCons solves most of the problems quite well for people
willing to learn how to use it.  Again, SCons isn't Make, and I'm glad it
isn't.  I have had the displeasure of using Make for years, and I would
prefer to use SCons for all of my new projects.

I rebuke some common misconceptions of SCons above, but I didn't get around
to explaining about all the great stuff SCons has that Make users complain
about not having! A shame really but it's late and I've ranted enough ;)

My two cents,
William

On Thu, Jun 4, 2015 at 9:32 PM, Evan Driscoll <driscoll at cs.wisc.edu> wrote:

> On 6/4/2015 1:40 PM, Paweł Tomulik wrote:
>
>> Consider these two worlds: developers and package maintainers. If you
>> give an automake-based project to a Debian package maintainer, (s)he'll
>> just grab it and make a package, because there is a "standard interface"
>> found in most automake-based project that is used (without much effort)
>> by package maintainers. If you give the same person a SCons-based
>> project, he'll probably fail at first place or at least spend much time
>> digging through the project-specific documentation, because it's not
>> known a priori how to build and preinstall (certain parts of) this
>> particular project to appropriate place(s). Often, there is simply no
>> such way.
>>
>
> For what it's worth, it's not just package maintainers. My two cents:
>
> I acted in a partial (and extremely occasional) role as a sysadmin for a
> while, installing packages to a network location so that they were easily
> available across the network. Because they were being installed to a
> non-standard location, we built almost all packages we installed by hand.
> (The usual Linuxy way of making a package is to embed paths to resources,
> rpaths, etc. in executables, so for many packages you can't just take a
> pre-built one and put it at a different location.)
>
> And as much as I don't ever want to work with autotools, it's relative
> inflexibility with regard to cross-platform builds (compared to something
> like SCons), and some more minor complaints about it from a end-user's
> perspective (i.e. someone building), the installation of autotools packages
> was almost always easy (except for resolving dependences). I know I can
> configure with --prefix=/the-network-drive/this-package-1.23/ and it will
> almost certainly install to that location. If it needs a library, you can
> almost certainly pass --with-libawesome=/path-to-libawesome.
>
> Non-autotools packages almost always took longer to install. I don't think
> I ever installed an SCons package in the course of this (I do use it for
> most of my own stuff), but I did encounter a number of other systems, most
> commonly plain-Make. Like the complaint on the Gentoo page says, you always
> have to look around for a while to figure out how to do anything besides
> "build with default settings", which are never suitable. The only thing
> that comes close to the autotools' standardness were CMake builds; I got
> pretty good at going through those quickly.
>
> Evan
>
> _______________________________________________
> Scons-users mailing list
> Scons-users at scons.org
> https://pairlist4.pair.net/mailman/listinfo/scons-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20150605/133c8435/attachment.html>