Hey Gabe, I don't have any strong feelings on this, just a couple of points.
1) I think we should support "backwards compatibility" if we do this by having symlinks from the old names to the new names. This way we don't break all of the scripts people have been using. 2) How much effort is this and would it be better worth your time to replace SCons with a better build system (e.g., cmake or bazel)? Additionally, a lot of our build headaches stem from the high level of coupling between all of the source directories which makes it impossible to build a subset of gem5 into a library. Would it make sense to tackle this instead of shoehorning it into SCons? I don't mean to discourage you from taking our current system and making it incrementally better! Cheers, Jason On Tue, Nov 21, 2017 at 6:01 AM Andreas Sandberg <andreas.sandb...@arm.com> wrote: > 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 _______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
