Re: [gem5-dev] gem5.opt => opt/gem5?

I thought about this a bit more, and one thing that would be worse under this scheme would be that generated source files would be generated multiple times when building multiple builds since they'd no longer be in a common location. I think it's pretty rare for people to build multiple builds,

Re: [gem5-dev] gem5.opt => opt/gem5?

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

Re: [gem5-dev] gem5.opt => opt/gem5?

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

Re: [gem5-dev] gem5.opt => opt/gem5?

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" wrote: > How would this work from the perspective of the

Re: [gem5-dev] gem5.opt => opt/gem5?

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

[gem5-dev] gem5.opt => opt/gem5?

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