Hey Gabe, Thanks for this, I think this change will be welcome. In line with your proposal, I think anything that makes Scons more explicit would be really helpful. A lot of the current setup does things implicitly, which has tripped me up several times.
One thing I feel is worth noting is that there is a desire to move away from SCons at some point (likely towards bazel: https://bazel.build/). This is definitely not something we could accomplish in the coming months, as I believe, at the very least, it would require breaking gem5 further down into separate modules; but it's something you should be aware is on some peoples' minds. We would value your input in this improvement as we flesh out the details. Kind regards, Bobby -- Dr. Bobby R. Bruce Room 3050, Kemper Hall, UC Davis Davis, CA, 95616 web: https://www.bobbybruce.net On Fri, Jul 9, 2021 at 4:35 PM Gabe Black via gem5-dev <gem5-dev@gem5.org> wrote: > Hi folks. In conjunction with my work for Google, I'm going to be focusing > a lot of attention on our SCons build system in the near future. One of the > things I'd like to do is to look into our current system of declaring > Source()s, SimObject()s, etc, and then going back to them later in the > SConscript to use "real" SCons mechanisms to set up the actual build rules. > > This level of indirection does a few things which I think are undesirable: > > 1. Abstracts our build system away from "pure" SCons, which makes it > harder to understand and makes it less like what any documentation you > might find for SCons would describe. > > 2. Adds extra machinery to our build which is more code to write, > maintain, etc. > > 3. Ties us more tightly to SCons and its ability to run arbitrary Python, > and moves us away from a purely rules based build where the actual build > process is handled by the tool and not our code. There are many other > aspects of our build which also do this, but this is one culprit. > > Expect changes related to this (and other fixes, cleanups, etc) to be > coming some time soon. I'm sure there are other things I'll end up doing > with our build going forward, but this is a good place to start for now. > > Gabe > _______________________________________________ > gem5-dev mailing list -- gem5-dev@gem5.org > To unsubscribe send an email to gem5-dev-le...@gem5.org > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
_______________________________________________ gem5-dev mailing list -- gem5-dev@gem5.org To unsubscribe send an email to gem5-dev-le...@gem5.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
