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

Bill Deegan bill at baddogconsulting.com
Wed Dec 5 16:28:15 EST 2018


SCons like make, waf, meson, cmake, are build tools, not build systems.
Build systems require you to write configuration files for the build tool
you are using.



On Wed, Dec 5, 2018 at 1:24 PM Hua Yanghao <huayanghao at gmail.com> wrote:

> 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!
> _______________________________________________
> Scons-users mailing list
> Scons-users at scons.org
> https://pairlist4.pair.net/mailman/listinfo/scons-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20181205/ed45610f/attachment-0001.html>


More information about the Scons-users mailing list