[Scons-users] Scons none-deterministic behavior for incremental build

[Hua Yanghao]

On Wed, Dec 5, 2018 at 5:38 PM Bill Deegan <bill at baddogconsulting.com> wrote:
>
> I'd say if you're handed a poorly implemented build system in SCons it can be fairly hard to unravel any issue you run into.
> And that such a situation is likely true regardless of the build system used.

So you admit with scons we still need to implement "the" build system,
right? I thought you were arguing that scons is already "the" build
system. :)

> Now if you're handed a well implemented build system in any build system, once again making changes to such is going to have a level of difficulty based on your familiarity with said build system.

True.

> The main problem I see with build systems implemented in SCons is that the creators of such build systems rarely take the time to understand how SCons is different from other build systems and how to best use SCons.
> Likely some improved documentation could help here.
> But 9 times out of 10 when I try to help said users and ask if they've read the documents... they haven't.. or they didn't understand them and didn't come to the community to ask for clarification.  Only coming with their misunderstanding of how SCons works to ask for help. Often asking how to make SCons function the way they think it functions, which of course since that understanding is often flawed is an impossible ask.
> (Of course this is not unique to SCons and happens with most software)

Well, I personally have read all the docs/wikis I could find and even
looked into scons source code to some extent. Yet still, having
flexibility is intrinsically making it easier to be used in completely
un-expected ways (remember the duplicate=True case for incremental
build failures?, there are still issues in scons without a clear
pattern of expectation, and admittedly it is easy to get wrong in
scons, don't compare with makefiles please ... scons is supposed to be
a huge leap.). I personally think scons has to limit its flexibility
to some extent, e.g. if there is known limitations, it at least should
not be set as the default, if not disabled completely. (refer to how
Linux maintains their system calls)

> Instead they often mash up build system logic with python overusing python instead of using it to simplify creating a build system.
> They see a hammer (python) and use it.
> They try to for build order rather than specifying dependencies using builders,scanners, emitters, etc.
> Of course the learning curve for such is a bit higher than make, but it's easier to make a correct build system once you understand such.
> And in many cases the stock builders are sufficient.

I find the stock builders are far from sufficient for my particular
case (a typical firmware cross-compilation), I just counted I have 20
custom builders. But scons builders are actually easy to implement. A
great library would have prevented user from using it wrong. My
ranking of scons is a super good library, but curio is a great one. I
think the problem is that scons tries to be extremely generic and is
for all kinds of languages. But in reality is that each language has
its own typical way of building and this part cannot really be
re-usable/common across languages. Some language even comes with their
own build system entirely.

Let me take a typical C code module as an example, what information
needs to be provided:
* a list of files to be built
* the way those files to be linked, are they goes into a static/shared
library, or links directly as an object file in the command line
* special flags that is required to build this system (private flags)
* special flags that needs to be given to the entire builds (public flags)
* dependent modules that will be automatically selected if this module
is enabled.

These 5 items if I have it I am so confidently to say that it covers
almost 99% of the build features one will ever want. However many of
them are entirely not applicable for other languages.

>
> Regardless we're (the community) is here to help people resolve those issues..

Always appreciate that! Thanks!