2

I am rather new with swig and I am getting an error that I cannot find. The error is:

/home/investigador/OMICRON-GNURadio/gr-freqAdaptiveOFDM/swig/../include/freqAdaptiveOFDM/mapper.h:39: Error: Syntax error in input(1).

And the file where the error is is this:

#ifndef INCLUDED_FREQADAPTIVEOFDM_SIGNAL_FIELD_H
#define INCLUDED_FREQADAPTIVEOFDM_SIGNAL_FIELD_H

#include <freqAdaptiveOFDM/api.h>
#include <gnuradio/digital/packet_header_default.h>

namespace gr {
namespace freqAdaptiveOFDM {

class FREQADAPTIVEOFDM_API signal_field : virtual public digital::packet_header_default
{
public:
    typedef boost::shared_ptr<signal_field> sptr;
    static sptr make();

protected:
    signal_field();
};

} // namespace freqAdaptiveOFDM
} // namespace gr

#endif /* INCLUDED_FREQADAPTIVEOFDM_SIGNAL_FIELD_H */

The line where the error is found is the class FREQADAPTIVEOFDM_API line. Thanks in advance for the help!

By the way, my swig file is the following:

#define freqAdaptiveOFDM_API
#define DIGITAL_API

%include "gnuradio.i"
%include "freqAdaptiveOFDM_swig_doc.i"

%{
#include "freqAdaptiveOFDM/mapper.h";
#include "freqAdaptiveOFDM/signal_field.h"
%}

%include "gnuradio/digital/packet_header_default.h"

%include "freqAdaptiveOFDM/mapper.h"
%include "freqAdaptiveOFDM/signal_field.h"

GR_SWIG_BLOCK_MAGIC2(freqAdaptiveOFDM, mapper);

%template(signal_field_sptr) boost::shared_ptr<gr::freqAdaptiveOFDM::signal_field>;

%pythoncode %{
signal_field_sptr.__repr__ = lambda self: "<signal_field>"
signal_field = signal_field.make;
%}
Samuel
  • 33
  • 1
  • 4
  • swig complains about mapper.h, line 39, not about the file you're sharing! – Marcus Müller Nov 24 '16 at 15:06
  • mapper.h is the first file I have shared. Line 39 is the line: "class FREQADAPTIVEOFDM_API signal_field : virtual public digital::packet_header_default ". – Samuel Nov 24 '16 at 17:12
  • oh, that file should *not* contain the include guard called `#ifndef INCLUDED_FREQADAPTIVEOFDM_SIGNAL_FIELD_H`. Have you copy & pasted this over from some file signal_field.h, maybe? – Marcus Müller Nov 24 '16 at 22:46
  • Yes, actually I have used another signal field file as base for modifying it. The problem was that this signal_field is not a block, but I must access it from my module, freqAdaptiveOFDM, but it was no visible. That's why I started editing the swig file. Regarding the #ifndef, why should it not be there? The file I have used as base has it and works fine. Sorry but as I said I'm new with this and I am trying to learn. – Samuel Nov 24 '16 at 23:02

2 Answers2

2

Most likely this is because FREQADAPTIVEOFDM_API is not defined anywhere in your SWIG interface.

Removing the wrongly capitalized 

#define freqAdaptiveOFDM_API

and replacing it by

#define FREQADAPTIVEOFDM_API

At the top of your .i file ought to solve that safely.

Marcus Müller
  • 34,677
  • 4
  • 53
  • 94
Flexo
  • 87,323
  • 22
  • 191
  • 272
  • No, that's not **solving** that. It's just cosmetics to hide the problme. That macro serves a purpose! In fact, the macro contains the platform-specific modifiers to export a symbol. So, this would only make matters worse. – Marcus Müller Nov 24 '16 at 22:47
  • Background info: GNU Radio modules follow a common pattern, and `MODULENAME_API` is always defined in include/modulename/api.h. if it isn't, someone removed it. – Marcus Müller Nov 24 '16 at 22:49
  • It should also be at the very top, as you correctly capitalized it, in the SWIG file, but the fact that it's here in wrong capitalization means someone replaced that, and probably did it automatically, and something's broken – Marcus Müller Nov 24 '16 at 22:57
  • @MarcusMüller sorry, but you're wrong - for the purpose of *SWIG* parsing that is the correct thing to do. The code that SWIG generates will still use exactly the correct definition of that macro, the actual compiler that comes across the code will still know how to do it right. – Flexo Nov 24 '16 at 22:57
  • ha, we simultaneously commented :) – Marcus Müller Nov 24 '16 at 22:58
  • so, I agree with your "fix", but the problem is an automatic search & replace that certainly broke stuff in several places – Marcus Müller Nov 24 '16 at 22:58
  • @MarcusMüller - I'm assuming that Samuel wrote the SWIG .i file themselves, in which case they simply added the wrong `#define` there. Either way in the SWIG .i file it should be #defined away – Flexo Nov 24 '16 at 22:59
  • I'm almost certain he didn't – this looks like the standard stub the GNU Radio module generation tool writes, with a bit of manual and search&replace f'up. – Marcus Müller Nov 24 '16 at 23:00
  • Yes, as you says FREQADAPTIVEOFDM_API is defined in the api.h file, included in the mapper.h file. – Samuel Nov 24 '16 at 23:03
  • If on Windows, `%include `. It helps with things like `__declspec` that are included in those API macros. – Mark Tolonen Nov 25 '16 at 00:43
1

You seem to have manually modified parts of your include files and broke it.

I can list a few of the potential problems below, but to be honest:

just use gr_modtool to create a clean module, then gr_modtool add all the stubs for blocks you want to have, then just copy over the actual methods and fields you need – leave the #includes alone, as long as you don't really understand what they're doing.

So, problems:

  • You have a file that you call mapper.h, but it has an includeguard clearly copy and pasted from another file: #ifndef INCLUDED_FREQADAPTIVEOFDM_SIGNAL_FIELD_H. This means in some cases, only one of the files is "relevant" at all, and the other one is basically treated as empty! Wikipedia "include guard".
  • your #define freqAdaptiveOFDM_API should be correctly capitalized. Did you perhaps copy and paste contents or whole files over and then used an automatic, case-insensitive search and replace on the original module name? You probably broke a lot of things accidentally that way. Basically, everyting in the C preprocessor and in the C++ language is case-sensitive.
  • #define DIGITAL_API doesn't look safe – I agree with Flexo, it's necessary to define the MODULENAME_API macro in your swig file, but only for your own module – I'm not quite sure why you need this here, but I guess stuff didn't build without it. So maybe you want to do a forward definition of the types from the digital API you use instead? Not quite sure, though – there might be cornercases where this is valid.
Marcus Müller
  • 34,677
  • 4
  • 53
  • 94