Hi Jason, thanks for the feedback. Replies inline. On Fri, Jan 28, 2022 at 2:45 PM Jason Lowe-Power <ja...@lowepower.com> wrote:
> Hi Gabe, > > Thanks for writing this up. The first part of your document is the best > documentation on the current build system I've seen to date! We should > convert it to markdown and put it up on the website! > > Overall, I really like the direction you're going here. I strongly agree > with the problems of the current build system that you enumerate. I also > strongly back the "there is one way to do it" idea from your solution. > > I have a couple of small concerns: > 1. I believe we should be able to use flat text files for configuring and > not require something as complex as kconfig. The option of kconfig is OK, > but flat text files give us the ability to offer defaults to users. > Kconfig does this. The config file is a text file, and you can provide one which only lists the options you care about and use the defconfig target (like menuconfig) which will non-interactively fill in the gaps with all default settings. This is essentially the same as what the build_opts files do. > 2. One requirement that wasn't listed is to make the common case easy. We > should allow users to build gem5 just as easily as they do today (i.e., > with a single simple command). > Even if starting from scratch requires two commands (set up build directory, compile), subsequent builds will still only take one. It would be feasible to put everything together into one, although there may be some weird cases/interactions that make that not work for some reason. I think there is a good chance it would work to configure and build all together. I also think, though, that the well established pattern from other projects is to configure and then build in two steps, and there's good reason for that. This isn't something we'd have to worry about up front, so we can figure it out further down the line once we have more concrete alternatives to compare. > 3. Backwards compatibility is important. There's a huge amount of > documentation written about gem5 all over the internet (e.g., on class > webpages for assignments), and we can't update all of it overnight. Keeping > at least a symlink to build/X86/gem5.opt, etc. will be important for our > many users. > Yes, I think this can be done incrementally, with backwards compatibility minimally during a transition period. > > It may be feasible to do this in steps. E.g., we could update the files in > build_opts to *require* all sticky variables and we could make all > variables either sticky or environment variables. Similarly, we could > remove the common build directory. These things would solve some of the > problems you enumerate without breaking compatibility. It's definitely > low-hanging fruit. > Yes, exactly, that's my plan. > > Cheers, > Jason > > > > On Wed, Jan 26, 2022 at 6:45 PM Gabe Black via gem5-dev <gem5-dev@gem5.org> > wrote: > >> Hi folks. I have a design document here: >> >> >> https://docs.google.com/document/d/11KspjOClPzGRqLUgNTfKQPrrkmsqx-2ulC71nZUJ2qA/edit?usp=sharing >> >> which describes my proposal to overhaul how gem5 builds are configured. >> Please take a look and provide feedback. >> >> Important points to note are (optionally but recommended) collapsing the >> global vs. variant separation in the build directory, and using a kconfig >> like system for enabling/disabling/configuring features, individual models, >> mixtures of ISAs, etc. Also setting up a build directory with a new config >> would be a separate step instead of being implied by the build path. All >> the details are in the doc, PTAL. >> >> 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 > >
_______________________________________________ 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
