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

2016-09-19 Thread 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 

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

2016-09-19 Thread Left Right
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,   wrote:
> Send Scons-dev mailing list submissions to
> scons-dev@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-requ...@scons.org
>
> You can reach the person managing the list at
> scons-dev-ow...@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 
> To: scons-dev@scons.org
> Subject: [Scons-dev] Don't want to use target as source...
> Message-ID:
> 
> 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