> I'm confused... we're already using the package= option, I just made changes
> like this:
> - code('%module(package="m5.internal") param_$cls')
> + code('%module(package="m5.internal.swig") $cls')
> What effect did that have in the older broken versions?
In the broken versions, the effect was that the python parts would end
up in the package, but the C++ parts would end up being global. So,
for example (I think this is a correct example), our C++ range
conflicted with python's builtin range().
> I think there were two main things that confused me:
> - the name 'params' isn't that descriptive, since the wrappers for the C++
> SimObjects end up in there as well as the generated FooParam structs and the
> other misc. param class definitions
params_ was simply a poor man's namespace. Feel free to pick a better name.
> - the process of programmatically importing things based on a partial string
> match of identifier names from a different package is just sketchy... it's
> understandable as a bug workaround, but doesn't seem like a long-term
> solution, particularly when the reasons behind it aren't documented :-)
I guess the documentation part was my fault since I put it in the commit
message and really should have put it in the importer code. I can copy it
there if you like (but there is no point if you're going to delete it.) As for
long-term solution, I agree that we should get rid of it some day (maybe today
is that day), but as long as we want to support older swig, I don't
see another way.
My only concern with moving forward swig versions is whether we want to support
distros like Ubuntu Hardy and RHEL5 (I'm not sure that RHEL5 actually has any
swig, but it would be old if they did, perhaps too old.)
> Perhaps... that crossed my mind. Or s/internal/swig/. The problem with
> "generated" is that, as I mentioned above, we have things that are generated
> three levels deep (python generated from .i files generated from C++ structs
> generated from python) so "generated" is kind of ambiguous when you're not
> clear on which layer you're talking about.
Whatever works for you works for me. I've worked on this for so long
that I just
got used to it and the names are pretty much historical at this point.
> Good point... seems like when we get to that point we should put most if not
> all the SimObject classes in namespaces, then the related parameters will
> just follow. I'm fine with leaving that to a future change though.
Yep.
Nate
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
