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
