Yeah, I thought that was going to be true after I'd sent my earlier email
and after I started working on it more, but it seemed that I had to import
systemc and tlm in src/python/m5/__init__.py to get them to show up in the
scripts. Is it some sort of thing where I'd have to import m5.systemc and
not just m5?

In any case I think it's working well enough for my purposes, one way or
the other.

Gabe

On Thu, Feb 21, 2019 at 2:29 AM Andreas Sandberg <[email protected]>
wrote:

> You should be able to include Python modules in any package using PySource
> in SCons. The first parameter informs the build system of the package name,
> so it should work just fine in EXTRAS.
>
> Cheers,
> Andreas
> On 20/02/2019 23:04, Gabe Black wrote:
>
> Oh, I see one point of confusion I had. I had thought the built in module
> initialization functions (pybind_init_core, pybind_init_stats, etc) were
> installing things under the m5 module, but they're really installing things
> under the _m5 module. I think I missed that since the _ isn't obvious in
> the variable that holds the module, m_m5.
>
> It seems fine to me to add a purely python m5 submodule (like m5.systemc
> and/or m5.tlm) and have that if nothing else just import and pass through
> the _m5 versions of the same. I think the problem then becomes, how do I
> add a systemc or tlm submodule to m5 without adding the code under
> src/python/m5? Putting the code there would be mostly ok since systemc and
> tlm are part of the main gem5 code base, but is there a way to bring that
> sort of thing in with EXTRAS? Maybe that's overkill for something that may
> not be that important, ie major bits of functionality that deserve highly
> integrated python interfaces but are still not part of the primary code
> base.
>
> Anyway, I think I know how to make what I was initially after work without
> having to do anything overly weird and without any additional machinery.
> Thanks!
>
> Gabe
>
> On Wed, Feb 20, 2019 at 8:38 AM Andreas Sandberg <[email protected]>
> wrote:
>
>> Hi Gabe,
>>
>> I think this might make sense. As you have probably seen already, the
>> main intention of the _m5 namespace is to hide the potentially clunky
>> C++-like interfaces from the normal m5 namespace. A common design
>> pattern for native Python packages used to be to have a native namespace
>> that provides a low-level API and then wrap it using Python code to
>> provide a more high-level API. "m5/event.py" is a pretty good example of
>> this design pattern.
>>
>> I'm not entirely sure how well it would work to combine native code and
>> Python code in the same namespace. Importing the m5 module and adding to
>> it could work, but it depends on the initialization order and seems a
>> bit scary. What we used to do in the past for this was to add a
>> pseudo-package in native Python code that just re-exports the native
>> functionality. Would this solve the problem?
>>
>> Cheers,
>> Andreas
>>
>> On 15/02/2019 02:10, Gabe Black wrote:
>> > Hey folks. For the systemc stuff I currently use our pybind11
>> > infrastructure to define and populate a _m5.systemc submodule, but I'd
>> like
>> > to make that m5.systemc so it seems less hacky to use explicitly, and
>> > perhaps even an m5.tlm.
>> >
>> > Is this something that makes sense to do? There aren't hooks for it atm,
>> > but I'm thinking I can get it to work by importing the m5 module in my
>> > EmbeddedPyBind hook and then adding things to it that way. That also
>> seems
>> > hacky, but should it work? Would it be worth adding hooks to add
>> submodules
>> > to the non-internal m5 module?
>> >
>> > Gabe
>> > _______________________________________________
>> > gem5-dev mailing list
>> > [email protected]
>> > http://m5sim.org/mailman/listinfo/gem5-dev
>> IMPORTANT NOTICE: The contents of this email and any attachments are
>> confidential and may also be privileged. If you are not the intended
>> recipient, please notify the sender immediately and do not disclose the
>> contents to any other person, use it for any purpose, or store or copy the
>> information in any medium. Thank you.
>>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev

Reply via email to