Hi Gabe, I can definitely see the reasoning behind this. I think revisiting this is a good idea. However, I'm a bit reluctant since it affects a lot of existing build scripts and test infrastructure.
Another benefit that you didn't mention is that this avoid some annoying "issues" when the build system runs tests. We currently run tests using the build/ARM/tests/opt/** targets. This would all become consistent with the rest of the build system. Another change we should consider making while we are doing this is to swap architecture and optimisation levels. The opt Arm target would then become build/opt/ARM/gem5.opt. That would be a lot nicer for code (e.g., libraries) that we share between different targets. Ideally, we should only rebuild the src/cpu and src/arch/ directories when switching targets, but that's a more ambitious goal. Cheers, Andreas On 21/11/2017 05:28, Gabe Black wrote:
Hi folks. I've been digging around in the scons files, and I was thinking about the possibility of treating opt, fast, debug, etc., as actual variants from the scons perspective instead of having them all live in the same directory but with different extensions. I think the biggest difference this might make is that, for instance, the opt version of the gem5 X86 binary would be build/X86/opt/gem5 and not build/X86/gem5.opt. There wouldn't be any amazing direct benefit from doing things that way that I can see at the moment, but it would make our build structure fit a little more naturally into the way scons wants to do things. It might also make it more feasible to use real scons builders for things like Source, etc., instead of wrapper classes. Another benefit would be if you wanted to compile all the files in a particular part of the source tree (like the unit tests, although those shouldn't be lumped together anyway), you could just give scons the path and it wouldn't build all possible versions of the sources in that directory, just the one in the variant you gave it. Using the unit tests as an example, you could run 'scons build/ARM/opt/unittest' and get the opt versions of all the unit tests. Any objections? Gabe _______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
