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.
_______________________________________________
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev
