Kaleb Barrett
Kaleb Barrett
Well, "typically". And I'm not sure how that's an unavoidable issue? Assuming we are using env variables. The Makefiles could define the following. ```makefile COCOTB_STARTUP_ROUTINES := "cocotb:_initialize_testbench();" COCOTB_PLUGINS := ""...
This belongs in cocotb-bus, so I'm transferring it.
> I have zoomed in as far as I can on my waveforms and everything looks to be changing exactly on the clock, no visible delta. In the Questa waveform...
@jwprice100 Has this been resolved with cocotb v1.7.2? The `libpythonX.X.so` should only be attempted to be opened by `dlopen` if `LIBPYTHON_LOC` were not set. The makefiles will error if `cocotb-config...
Comment added to newsfrag as to justification and what to change the import to.
Actually one last question is, should this module be made private now?
Why is there this discussion and decision to wait for future infrastructure updates when simply supporting `build.apt_packages` and `build.commands` together would solve the original problem? Not supporting it doesn't seem...
It seems that `build.commands` was introduced to allow user full customization of the build process and override the standard process. That's cool and all, but it was introduced the infrastructure...
Yes, I understand what's intended here. What I'm saying is that a solution achievable *now* would be a separate feature that would allow the user to override the `build` stage...
> Yes if they can live with that it would be much simpler. Unfortunately we can't since we service SV code as well. We can't know what PLI interface returned...