# Clarification **URL:** \ **Category:** GNU Radio\ **Created:** [August 7, 2014, 11:11pm UTC](https://www.ruby-forum.com/t/clarification/231436 "2014-08-07T23:11:47Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![addis\_a](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c4cdca/32.png) [@addis\_a](https://www.ruby-forum.com/u/addis_a)\ **Post date:** [August 7, 2014, 11:11pm UTC](https://www.ruby-forum.com/t/clarification/231436/1 "2014-08-07T23:11:47Z")
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. [http://gnuradio.org/redmine/projects/gnuradio/wiki/Move\_3-6\_to\_3-7?version=7](http://gnuradio.org/redmine/projects/gnuradio/wiki/Move_3-6_to_3-7?version=7) 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. ---
**Author:** ![vh1](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/v/278dde/32.png) [@vh1](https://www.ruby-forum.com/u/vh1)\ **Post date:** [August 8, 2014, 10:20am UTC](https://www.ruby-forum.com/t/clarification/231436/2 "2014-08-08T10:20:37Z")
Hi Mike, 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: namespace gr{ namespace modname{ class MODNAME\_API blockname : virtual public gr::block { … public: virtual set\_my\_herring\_count(int herrings) = 0; … }; } } 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. Greetings, Marcus ---
**Author:** ![vh1](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/v/278dde/32.png) [@vh1](https://www.ruby-forum.com/u/vh1)\ **Post date:** [August 8, 2014, 11:54am UTC](https://www.ruby-forum.com/t/clarification/231436/3 "2014-08-08T11:54:01Z")
Hello, I have the same problem before. After adding the virtual function in include directory and other are done. You need to “make clean” and after that you just make and make install. The “AttributeError: ‘module’ object has no attribute” will solve. I have no idea why the swig won’t update when you add new virtual function in include file if you have done make. Jeff Guo 2014-08-08 16:19 GMT+08:00 Marcus Müller [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid): ---
**Author:** ![vh1](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/v/278dde/32.png) [@vh1](https://www.ruby-forum.com/u/vh1)\ **Post date:** [August 8, 2014, 12:23pm UTC](https://www.ruby-forum.com/t/clarification/231436/4 "2014-08-08T12:23:48Z")
W dniu 08.08.2014 o 11:53, 奕佑 pisze: > function in include file if you have done make. > > Jeff Guo Hi, 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? Piotr K. ---
**Author:** ![vh1](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/v/278dde/32.png) [@vh1](https://www.ruby-forum.com/u/vh1)\ **Post date:** [August 8, 2014, 4:10pm UTC](https://www.ruby-forum.com/t/clarification/231436/5 "2014-08-08T16:10:31Z")
On 08/08/2014 03:25 PM, Tom R. wrote: > 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. Thanks – I was thinking the same lines and starting to doubt myself. > 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. Quick tip to those who don’t know: We have build targets for C++ only, so you can do $ make gnuradio-MODULENAME to only run the C++ compilation and skip swig. Useful for fast iterating when debugging with tests. M ---
**Author:** ![vh1](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/v/278dde/32.png) [@vh1](https://www.ruby-forum.com/u/vh1)\ **Post date:** [August 9, 2014, 4:26am UTC](https://www.ruby-forum.com/t/clarification/231436/6 "2014-08-09T04:26:31Z")
Hello, 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 ? Jeff Guo 2014-08-08 22:09 GMT+08:00 Martin B. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid): ---
**Author:** ![vh1](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/v/278dde/32.png) [@vh1](https://www.ruby-forum.com/u/vh1)\ **Post date:** [August 8, 2014, 3:27pm UTC](https://www.ruby-forum.com/t/clarification/231436/7 "2014-08-08T15:27:02Z")
On Fri, Aug 8, 2014 at 6:22 AM, Perper [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > > 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. Tom ---
**Author:** ![vh1](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/v/278dde/32.png) [@vh1](https://www.ruby-forum.com/u/vh1)\ **Post date:** [August 9, 2014, 3:14pm UTC](https://www.ruby-forum.com/t/clarification/231436/8 "2014-08-09T15:14:17Z")
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. M ---
**Author:** ![vh1](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/v/278dde/32.png) [@vh1](https://www.ruby-forum.com/u/vh1)\ **Post date:** [August 11, 2014, 11:14pm UTC](https://www.ruby-forum.com/t/clarification/231436/9 "2014-08-11T23:14:14Z")
W dniu 08.08.2014 o 15:25, Tom R. pisze: > ``` > > 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. Best Regards, Piotr ---
**Author:** ![vh1](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/v/278dde/32.png) [@vh1](https://www.ruby-forum.com/u/vh1)\ **Post date:** [August 12, 2014, 2:43am UTC](https://www.ruby-forum.com/t/clarification/231436/10 "2014-08-12T02:43:18Z")
Hi Piotr, 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. Best, Jeff Guo 2014-08-12 5:12 GMT+08:00 Perper [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid):