[Scons-dev] Scons-dev Digest, Vol 57, Issue 9

Mon Sep 19 03:08:48 EDT 2016

OK, after the dust settled, I regret the tone of the message, but
there's really nothing of interest in it for the users mailing list.

This is really intended for the developers of Scons.  For the last two
months I've been looking for a build tool to build two things: Go
programs and Docker images.  I've considered and even to some extent
wrote working builds in:
- SCons
- WAF
- Gradle
- tup
- Blaze
- Stag
I didn't really try to use Make, but it's not difficult to see how
that would fit into the picture.
The unfortunate conclusion is that all these "tools" are very poorly
engineered and some are also poorly executed.  They lack some obvious
basic functionality, they assume too much about what the user of the
tool is trying to do, impose arbitrary restrictions unrelated to the
task the user is trying to perform.  Of all of this collection SCons
appears to be the most tolerable option.  I don't suppose you are
interested in any sort of feedback on other tools, but there are some
thing you might reconsider about SCons.  This isn't about the user
experience, this is about the code of the program and about the
decisions which made it to be this way.

1. Classes with several dozens of methods.  There really shouldn't be this many.
2. Comments and documentation are unhelpful.  They are written from
the perspective of someone who wrote the code, but they don't help the
reader.  There is no birds-eye overview of the system.  (But, compared
to the list above, at least you have some).
3. Everything happens "by chance", when you read the code you always
need to guess the state of the object the method it is working with,
this is including the class of the object and the values of several
dozens of fields the object has: you pull a rope at one end, and from
the other end firebreathing dragons begin to emerge.
4. Object's functionality is encoded into strings which are passed
around at will and are next to impossible to track before the program
is actually executed.
5. There isn't that much of codebase, but it is so immensely twisted
that following the path of code execution is very difficult: you keep
going in circles, you keep wondering about some functions with
suggestive names never being called.
6. Lots of implicit assumptions, for whatever reason inputs and
outputs are assumed to be actual files on filesystem.  I've never seen
this being the case, unless in helloworld examples.
7. Functionality is duplicated many times over.  Why is there emitter
and builder?  Why is there action and command?  Why are there
factories, suffixes and scanners?  Jobs and tasks?  The code clarity
could be greatly improved if these things are deduplicated.  The
answers might seem obvious to you as someone who wrote these, but if
you try to don the hat of the reader, you'll see how they don't make
sense.

I don't intend for this message to grow into a discussion, I just put
it here as a feedback on the state of the project as perceived by an
external observer.  But if you are interested, I can expand on the
bullet points above.  I understand that this much criticism is hard to
take, especially from an unknown outsider.  Anyhow, believe it or not,
this was written in hopes to actually improve this program.  Hope
you'll see it that way.

Best.

Oleg

On Mon, Sep 19, 2016 at 8:43 AM,  <scons-dev-request at scons.org> wrote:
> Send Scons-dev mailing list submissions to
>         scons-dev at scons.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://pairlist2.pair.net/mailman/listinfo/scons-dev
> or, via email, send a message with subject or body 'help' to
>         scons-dev-request at scons.org
>
> You can reach the person managing the list at
>         scons-dev-owner at scons.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Scons-dev digest..."
>
>
> Today's Topics:
>
>    1. Don't want to use target as source... (Left Right)
>    2. Re: Don't want to use target as source... (Bill Deegan)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 18 Sep 2016 18:45:10 +0300
> From: Left Right <olegsivokon at gmail.com>
> To: scons-dev at scons.org
> Subject: [Scons-dev] Don't want to use target as source...
> Message-ID:
>         <CAJQBtgmecnWasHHUZaCnM1F2aZjk953o42eHkbRNinU4wUXf-A at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Hello,
>
> I'm trying to write a builder which doesn't take a file as a source.
> The whole area of source_factory and target_factory in Builders is a
> huge mess, and it's impossible to understand why things produce the
> results they do.  For instance, one extremely undesirable behavior, of
> which I cannot find the source is that if the source isn't given, then
> the target assumed to be the source.
>
> Basically, I need something that works like Library() builder.  I
> tried to read the code, but after ten delegations of delegations to
> delegations to other delegations I've lost track.  Even simpler.  I
> want the source to be a directory.  Not a file.  I can write a scanner
> that generates all file names given the directory name, but I keep
> running into unrelated errors in Scons code which assume too much
> about what things can be built and the way to do that, and they are
> never right.
>
> Bottom line: isn't there any way to circumvent all the layers of
> needless abstraction on top of Node and Builder classes and just have
> access to the database and tasks / jobs?  Example would help hundred
> times more than an explanation.
>
> Thanks.
>
>
> ------------------------------
>
> Message: 2
> Date: Sun, 18 Sep 2016 10:09:28 -0700
> From: Bill Deegan <bill at baddogconsulting.com>
> To: SCons developer list <scons-dev at scons.org>, SCons users mailing
>         list <scons-users at scons.org>
> Subject: Re: [Scons-dev] Don't want to use target as source...
> Message-ID:
>         <CAEyG4CGRLLK3v_2k-vOUxKme72hXPBABd=tOm0tL3vQSQ5wuaA at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> This message should go on the users mailing list.
> The dev mailing list is for development of scons itself.
>
>
>
> On Sun, Sep 18, 2016 at 8:45 AM, Left Right <olegsivokon at gmail.com> wrote:
>
>> Hello,
>>
>> I'm trying to write a builder which doesn't take a file as a source.
>> The whole area of source_factory and target_factory in Builders is a
>> huge mess, and it's impossible to understand why things produce the
>> results they do.  For instance, one extremely undesirable behavior, of
>> which I cannot find the source is that if the source isn't given, then
>> the target assumed to be the source.
>>
>> Basically, I need something that works like Library() builder.  I
>> tried to read the code, but after ten delegations of delegations to
>> delegations to other delegations I've lost track.  Even simpler.  I
>> want the source to be a directory.  Not a file.  I can write a scanner
>> that generates all file names given the directory name, but I keep
>> running into unrelated errors in Scons code which assume too much
>> about what things can be built and the way to do that, and they are
>> never right.
>>
>> Bottom line: isn't there any way to circumvent all the layers of
>> needless abstraction on top of Node and Builder classes and just have
>> access to the database and tasks / jobs?  Example would help hundred
>> times more than an explanation.
>>
>> Thanks.
>> _______________________________________________
>> Scons-dev mailing list
>> Scons-dev at scons.org
>> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <https://pairlist2.pair.net/pipermail/scons-dev/attachments/20160918/00ada432/attachment-0001.html>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Scons-dev mailing list
> Scons-dev at scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
>
> ------------------------------
>
> End of Scons-dev Digest, Vol 57, Issue 9
> ****************************************