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

[Dirk Bächle]

Hi Oleg,

thanks a lot for taking the time to write up your questions and suggestions. I'm really interested in hearing more about how you 
think SCons could be improved. You'll find some specific questions and comments inline below...

Please bear in mind that SCons is a file-centric build system, so it's designed around the idea of having files as input and output 
to the single build steps. In particular, you usually need a file (Node) to get at its contents for deciding whether the file has 
changed such that depending targets can get updated automatically.
Leading to the first question of how to decide whether a "directory" (given as source in your intended case) is up-to-date or not?
While answering this question, please take into account that possibly not all files that "live" in this folder physically exist yet. 
Some of them might get created (or updated) during the build process, but we still want SCons to handle dependencies on these files 
automatically such that we can guarantee a correct build for the user.

This is a tiny aspect of the "can of worms" ;) that you opened with your last email, but it shows that we are moving away from the 
actually intended usage of SCons and that you try to bend SCons the way you would like it to behave. It follows logically for me 
that you encounter problems and questions, and that a larger knowledge about SCons' internal workings is required in this case.
I would also expect that someone who is this interested in the "inner clockworks" at least tries to get at additional information by 
introducing his/her problem on the developer mailing list and asking for further advice and pointers to helpful documentation.
You have done 1), but 2)...well, not so much I'm afraid.
Leading me to my second upfront question: Which documentation have you read so far? (Please be specific, and name the title of the 
SCons documents, or give the URLs.) Did you find the ToolsForFools guide at https://bitbucket.org/scons/scons/wiki/ToolsForFools? Do 
you know that we have a document describing the underlying design of SCons, although it's a bit outdated?

Best regards,

Dirk

On 19.09.2016 09:08, Left Right wrote:
> 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.

Please point to a concrete example for this, and tell us how to improve. How many methods would be tolerable in your view, and why 
exactly would the SCons core benefit from it?

> 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).

As mentioned in my reply above, we have such documentation as well...possibly spread across several places, but it exists. If you 
think the access to these informations should be made easier, please be our guest and make some concrete suggestions about how to 
restructure the existing texts and documentation in general. If, for example, you'd like to open a Wiki page with all the required 
pointers that seem necessary for what you have in mind, we can surely give you all the required access rights that you'd need for that.

> 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.

Yes, build systems are complex. (Sorry, I can't give a more specific answer to a vague statement like "everything happens by chance").

> 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.

Please give a concrete example for this.

> 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.

Again, build systems are complex. (see above)

> 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.

This is one of the foundations of SCons' design, and there is no actual reason behind it. It just happens to be like this and 
instead of banging your head against this wall you might be better off by looking for a different build system like "doit" (there 
are tons of others probably). I'd really hate to lose you as a user of SCons though...;)

> 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.

If you have found places where code is copied verbatim, I'd really like to know the name of the files (modules) and line ranges. If 
possible, we can work on factoring them out to a common function.
However, some of the problems that you seem to have in understanding the inner workings of SCons might come from the fact that you 
didn't find (let alone read) the correct documentation yet. So would it be okay for you, if we come back to these questions once 
you've done that in the first place?

>
> 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.
>

I do, and I hope my comments and questions above show that I really take this seriously. I'm looking forward to hearing from you soon.