The opt and debug variants would still be separated, just in different directories instead of with different extensions, ie foo.do and foo.o => debug/foo.o and opt/foo.o.
Gabe On Nov 20, 2017 9:36 PM, "Sam Xi" <[email protected]> wrote: > How would this work from the perspective of the object files and > incremental builds? Suppose I build the opt variant and then the debug > variant, change a file, then rebuild the opt variant. Would the entire opt > variant need to be rebuilt because the debug variant blew away all of those > object files, or would incremental builds be possible now with this > separation? > > On Tue, Nov 21, 2017, 12:28 AM Gabe Black <[email protected]> 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 > > [email protected] > > http://m5sim.org/mailman/listinfo/gem5-dev > > -- > Thanks, > > Sam Xi > Harvard University > Computer Science, Ph.D. Candidate > http://www.samxi.org > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
