> On 2011-09-25 09:21:43, Nathan Binkert wrote: > > Make sure that you don't run afoul of the problem in changeset > > c6e283904437. We used to have something like this, but I undid it because > > it broke older versions of swig. You have a different approach here, but > > I'd hate to have you reintroduce a bug. > > Steve Reinhardt wrote: > Ugh, that's a bummer... thanks for pointing it out. Is it unreasonable > just to advance the minimum required swig version? I see that 1.3.39 came > out in 3/09 (2.5 yrs ago), and the latest release is 2.0.4, so supporting > versions older than 1.3.39 doesn't seem terribly compelling to me. > > At least this explains the weird mess that is the status quo... I > wondered what you were thinking when you did it the way you did :-). > > Gabe Black wrote: > I was also going to suggest bumping the minimum version number. Newer > doesn't necessarily mean better since the new versions have bugs too (if I > remember right, 2.0.4 + gcc 4.6.1 doesn't build but 2.0.3 does) so we > shouldn't be *too* aggressive, but bumping beyond several year old bugs seems > reasonable.
I don't have a problem with it. Though we shouldn't go as much in terms of years, but rather we should pick distros that we want to support. The main reason for supporting the version that we did was because zizzer was running 8.04. - Nathan ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/878/#review1571 ----------------------------------------------------------- On 2011-09-24 09:51:34, Steve Reinhardt wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.m5sim.org/r/878/ > ----------------------------------------------------------- > > (Updated 2011-09-24 09:51:34) > > > Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and > Nathan Binkert. > > > Summary > ------- > > swig: move all swigged objects into m5.internal.swig package > > SWIG-generated packages for params, enums, wrapped C++ SimObjects, > etc. were being generated directly into m5.internal, with some > funky code to import some of the declarations into m5.internal.params. > Moved all generated packages under m5.internal.swig and imported > things directly from there where necessary. Cleaned up some > exposed loose ends. Turns out m5.internal.params doesn't really seem > to be needed, so it's gone now. > > Also renamed param_Foo packages that wrap both the C++ version of > Foo and FooParams to just Foo; now that they're under a separate > subpackage there's no ambiguity with the primary Python objects, > and no need to have the param_ prefix to support the funky > importing into internal.params. > > > Diffs > ----- > > src/SConscript d182a475a668 > src/python/SConscript d182a475a668 > src/python/m5/SimObject.py d182a475a668 > src/python/m5/internal/params.py d182a475a668 > src/python/m5/internal/swig/__init__.py PRE-CREATION > src/python/m5/objects/__init__.py d182a475a668 > src/python/m5/params.py d182a475a668 > src/python/swig/inet.i d182a475a668 > src/python/swig/time.i d182a475a668 > > Diff: http://reviews.m5sim.org/r/878/diff > > > Testing > ------- > > > Thanks, > > Steve > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
