Как использовать SWIG для генерации C # в Linux, когда он может генерироваться правильно на Win7 - PullRequest
Новая
       8

Как использовать SWIG для генерации C # в Linux, когда он может генерироваться правильно на Win7

0 голосов
/ 21 февраля 2019

Я использую SWIG 3.0.12 для создания оболочки C # из C ++ на Win7.Команда: 

swig.exe -c++ -csharp -namespace DS -DWIN32 -outdir D:/DS_CSharp/GeneratedSWIG DS.i

Это прекрасно работает на Windows.Наш C ++ и SWIG сгенерировали оболочку, скомпилированную в Visual Studio, и скомпилированная dll может быть вызвана в коде C #.

Теперь нам нужно переместить код C ++ и C # в Debian 9 с помощью gcc и mono.Тогда какова правильная команда для генерации кода оболочки в Linux?

В приведенной выше команде Win7 есть макрос "WIN32", я думаю, что это не нужно в Linux.Сгенерированный файл оболочки .cxx на Win7 содержит ряд условных определений, которые выглядят для Windwos или GCC, например: 

#ifndef SWIGEXPORT
# if defined(_WIN32) || defined(__WIN32__) || defined(__CYGWIN__)
#   if defined(STATIC_LINKED)
#     define SWIGEXPORT
#   else
#     define SWIGEXPORT __declspec(dllexport)
#   endif
# else
#   if defined(__GNUC__) && defined(GCC_HASCLASSVISIBILITY)
#     define SWIGEXPORT __attribute__ ((visibility("default")))
#   else
#     define SWIGEXPORT
#   endif
# endif
#endif

Как определить правильные макросы для Linux и gcc?

Кроме того, наш файл DS.i также содержит включение, относящееся к Windows, я не уверен, удаляем ли мы это и для Linux: 

%include <windows.i>
%include <std_string.i>
%include <std_wstring.i>
... ...

1 Ответ

0 голосов
/ 22 февраля 2019 
swig.exe -c++ -csharp -namespace DS -outdir D:/DS_CSharp/GeneratedSWIG DS.i

__GNUC__ автоматически определяется при сборке сгенерированного кода с использованием gcc.Это проверяется путем добавления распечатки в макроопределениях, например #warning my messages.

...