I still have the problem with the AttributeError: ‘module’ object has
no attribute problem for my OOT module. Really clutching at straws
now, hair all gone. Can anyone explain in plain English what the
following advice from the WiKi means? I am sure it is 100% clear to
whoever wrote it but it means little to me.
Make sure the methods in include/modname/blockname.h are declared pure
virtual so that blockname can remain an abstract class.
Following that is the advice that If blockname is not abstract, your
code may compile but SWIG will interpret the declaration as the
concrete class instead of your blockname_impl class. At runtime this
will cause an error like ImportError: […] undefined symbol when the
Python interpreter attempts to load your SWIGged object code.
Well that’s more or less what is happening but it might not be the
cause.
puh, you’re asking us to translate C++ish to plain English. C++'s
language design isn’t too open for such unclean and incomplete concepts
as the English language
I’ll try:
Make sure the methods in include/modname/blockname.h are declared pure
virtual so that blockname can remain an abstract class.
Methods of your base class as defined in include/modname/blockname.h
should not be fully fledged callable methods, but only entries in the
table that lets the compiler know that there must be a subclass actually
implementing this method.
In practice, this looks like:
The trick is that this class cannot ever be “complete”, because there’s
a method defined, but you don’t implement
blockname::set_my_herring_count(int) in blockname itself. Now, as this
class is incomplete (“abstract”), this guarantees that SWIG doesn’t try
to directly instantiate blockname, and the only way to get an instance
of blockname is through the make call.
I also ran into this problem that SWIG files aren’t generated again when
I change a block interface in a header from “include/” directory. I
always have to make clean when I do that in order to successfully
compile. Can it be easily corrected by editing cmake files?
I noticed that even I add a space in c++. make will recompile it. Is
there
any command to fore it to rebuild swing or just clean swing and then
doing
“make” will compilation swig ?
I have no idea why the swig won’t update when you add new virtual
compile. Can it be easily corrected by editing cmake files?
Piotr K.
Are you guys sure about that behavior? Any change to an include file
that’s
referenced by SWIG (if you’re using gr_modtool to add new blocks, then
this
is always true), then any change, even just adding a space, to the
public
header file will trigger a rerun of swig. You should /not/ have to run
“make clean” ever time you update your header file.
In fact, I often find this problematic if, for instance, I accidentally
save a silly change in block.h that launches a rebuild of everything.
If you’re honestly seeing this happen, we’ll definitely try to track
down
the reason why.
That’s normal, make will recompile every time it sees a change in the
file,
regardless how small.
A useful tool when compiling often is ccache. Check it out!
There are targets for swig, but when I need a swig recompile I usually
clear the swig folder from the build dir and call make again. That will
keep the object files from the lib/ compilation around and only rebuild
swig components.
> install. The "AttributeError: 'module' object has no attribute" will
I also ran into this problem that SWIG files aren't generated
that’s referenced by SWIG (if you’re using gr_modtool to add new
down the reason why.
Tom
Hi Tom,
I created the project with gr_modtool. Now I cannot confirm that there
was any error in gr_modtool as build system in projects created with
current version of this tool act as you describe. It’s probable that I
accidentally changed something that resulted with such changed behaviour
of build system in relation to SWIG generated files.
We are not saying gr_modtool are the root problem, you can add a virtual
function in gr-yourmod/include/yourmod/myblock.h and implement virtual
function in gr-yourmod/lib/myblock_impl.h myblock_impl.cc. Before you
add
virtual function, you compile module first. After add virtual
function, compile it again and check virtual function is in
gr-yourmod/build/swig/myblock_swig.py file.
