Fehler bei der Verwendung von swig: Syntaxfehler im Eingang (1)

Question

Ich bin ziemlich neu mit swig und ich bekomme einen Fehler, den ich nicht finden kann. Der Fehler lautet:

/home/investigador/OMICRON-GNURadio/gr-freqAdaptiveOFDM/swig/../include/freqAdaptiveOFDM/mapper.h:39: Fehler: Syntaxfehler in Eingabe (1).

Und die Datei, wo der Fehler ist, ist dies:

#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 */ 

Die Linie, wo der Fehler gefunden wird, ist die Klasse FREQADAPTIVEOFDM_API Linie. Vielen Dank im Voraus für die Hilfe!

By the way, meine swig Datei ist folgende:

#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; 
%} 

Answer 1

Wahrscheinlich ist dies, weil FREQADAPTIVEOFDM_API nicht überall in Ihrem SWIG Schnittstelle definiert ist.

Entfernen der fälschlicherweise aktiviert

#define freqAdaptiveOFDM_API 

und es durch

#define FREQADAPTIVEOFDM_API 

An der Spitze Ihrer .i-Datei ersetzen soll, dass sicher lösen.

Answer 2

Sie scheinen Teile Ihrer Include-Dateien manuell geändert zu haben und haben sie zerstört.

Ich kann ein paar der möglichen Probleme Liste unten, aber um ehrlich zu sein:

nur gr_modtool mit einem sauberen Modul erstellen, dann gr_modtool add alle Stubs für Blöcke, die Sie haben wollen, dann kopieren Sie einfach über die aktuelle Methoden und Felder, die Sie brauchen - lassen Sie die #includes in Ruhe, solange Sie nicht wirklich verstehen, was sie tun. So

, Probleme:

• Sie haben eine Datei, die Sie mapper.h nennen, aber es hat eine includeguard deutlich kopieren und aus einer anderen Datei eingefügt: #ifndef INCLUDED_FREQADAPTIVEOFDM_SIGNAL_FIELD_H. Dies bedeutet in einigen Fällen, dass nur eine der Dateien überhaupt "relevant" ist, und die andere wird grundsätzlich als leer behandelt! Wikipedia "include guard".
• Ihre #define freqAdaptiveOFDM_API sollte richtig groß geschrieben werden. Haben Sie vielleicht Inhalte oder ganze Dateien kopiert und eingefügt und dann eine automatische, Groß-/Kleinschreibung nicht berücksichtigende Suche nach dem ursprünglichen Modulnamen verwendet? Wahrscheinlich hast du auf diese Weise viele Dinge kaputt gemacht. Grundsätzlich wird bei Everying im C-Präprozessor und in der C++ - Sprache zwischen Groß- und Kleinschreibung unterschieden.
• #define DIGITAL_API sieht nicht sicher - Ich stimme mit Flexo überein, es ist notwendig, das MODULENAME_API Makro in Ihrer SWIG-Datei zu definieren, aber nur für Ihr eigenes Modul - ich bin mir nicht ganz sicher, warum Sie das hier brauchen, aber ich denke, Zeug habe nicht ohne es gebaut. Vielleicht möchten Sie also eine Vorwärtsdefinition der Typen von der digitalen API, die Sie verwenden, machen? Nicht ganz sicher, aber es könnte Ecken geben, wo das gilt.