On Sun, Sep 25, 2011 at 6:25 PM, nathan binkert <[email protected]> wrote:
> Since they were being imported via internal.params and I got rid of that > package, I had to change something... I suppose I could have imported them > from internal.swig.wherever but at the time it just seemed asymmetric that > some of the swig/*.i files ended up in their own packages but these others > didn't (and you couldn't tell by looking at the .i files where they ended > up), so it just seemed more regular to make them be their own packages too. > If there's a good reason not to do it that way, I don't mind revisiting it. >> >> > Makes sense. I just didn't understand. > > Nate > So now that I've thought about this... is 'm5.internal.swig' the best name for this package? Originally I called it that because I thought that all the swig-generated python wrapper code would go there, but this exchange reminded me that these other packages in src/python/swig generate their own packages under m5.internal instead. It even seems a bit confusing that there's an internal.swig package but the files in swig/*.i don't generate packages that go in there. In fact it looks like everything in m5.internal is swig-generated, so m5.internal.swig is maybe kind of redundantly misleading. In fact the category of stuff in m5.internal.swig is kind of "meta-generated", in the sense that considering the swig-generated python as auto-generated code, this is the python that's generated from auto-generated swig wrappers. Maybe that's not a sufficiently meaningful distinction to need its own sub-package. There are actually several categories of swig wrapped things that end up here: - C++ SimObjects - the auto-generated C++ SimObjectParam structs (there's three layers of auto-generated code!) - Enum classes used as SimObject params - other classes used as SimObject params that aren't native types or SimObject pointers or Enums (mostly if not entirely vectors of other types at this point) Since these all generate their own packages (e.g., the SystemParam object is in the m5.internal.swig.System package), maybe it makes sense to leave them directly in m5.internal instead of creating a subpackage... I'd still lean toward getting rid of m5.internal.params, but that might maintain backward compatibility with those older versions of swig. I guess my main motivation for getting rid of m5.internal.params is that it seemed confusing and unnecessary, and I think this patch shows that it's unnecessary, so I'd still like to get rid of it. I'm just not completely confident that what I've replaced it with is the best solution. Thoughts? Steve _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
