C++11 with CMake

C++11 with CMake

I'm trying to get swig works with my c++ module and python. For that
I use CMake and GCC.

I've currently other projects with CMake files who works on c++14.
And I encounter errors for SWIG module:

/usr/include/c++/5/bits/c++0x_warning.h:32: Error:
CPP #error "This file requires compiler and library support \
for the ISO C++ 2011 standard. This support must be enabled \
with the -std=c++11 or -std=gnu++11 compiler options.". Use the
-cpperraswarn option to continue swig processing.

But I've define this in my CMake with "-std=c++14", so I don't
understand why swig warns about that. Here is my files:

I notice that if I remove "SET_SOURCE_FILES_PROPERTIES(coreswig.i
PROPERTIES SWIG_FLAGS "-includeall")", ERROR disappear but no longer
see macros define in .h...

How I can solve this problem ?

I also noticed that when I add .h, it seems I've to redefined each
MACROS... In fact I have a little trouble understanding what to put
or not in the file coreswig.i.

------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford_______________________________________________
Swig-user mailing list
[hidden email]https://lists.sourceforge.net/lists/listinfo/swig-user

Re: C++11 with CMake

I'm trying to get swig works with my c++ module and python. For that
I use CMake and GCC.

I've currently other projects with CMake files who works on c++14.
And I encounter errors for SWIG module:

/usr/include/c++/5/bits/c++0x_warning.h:32: Error:
CPP #error "This file requires compiler and library support \
for the ISO C++ 2011 standard. This support must be enabled \
with the -std=c++11 or -std=gnu++11 compiler options.". Use the
-cpperraswarn option to continue swig processing.

But I've define this in my CMake with "-std=c++14", so I don't
understand why swig warns about that. Here is my files:

I notice that if I remove "SET_SOURCE_FILES_PROPERTIES(coreswig.i
PROPERTIES SWIG_FLAGS "-includeall")", ERROR disappear but no longer
see macros define in .h...

How I can solve this problem ?

I also noticed that when I add .h, it seems I've to redefined each
MACROS... In fact I have a little trouble understanding what to put
or not in the file coreswig.i.

Use the compiler's preprocessor and SWIG's preprocessor and look at the actual headers to see what macros you need to define/undefine. BTW, including platform specific headers and using -includeall usually causes problems as you end up wrapping too much low level junk. You are usually better off carefully selecting the headers that provide the API you need and then wrap those.

I'm trying to get swig works with my c++ module and
python. For that I use CMake and GCC.

I've currently other projects with CMake files who works
on c++14. And I encounter errors for SWIG module:

/usr/include/c++/5/bits/c++0x_warning.h:32:
Error: CPP #error "This file requires compiler and
library support \
for the ISO C++ 2011 standard. This support must be
enabled \
with the -std=c++11 or -std=gnu++11 compiler
options.". Use the -cpperraswarn option to continue
swig processing.

But I've define this in my CMake with "-std=c++14", so I
don't understand why swig warns about that. Here is my
files:

I notice that if I remove "SET_SOURCE_FILES_PROPERTIES(coreswig.i
PROPERTIES SWIG_FLAGS "-includeall")", ERROR disappear
but no longer see macros define in .h...

How I can solve this problem ?

I also noticed that when I add .h, it seems I've to
redefined each MACROS... In fact I have a little trouble
understanding what to put or not in the file coreswig.i.

Use the compiler's preprocessor and SWIG's preprocessor
and look at the actual headers to see what macros you need
to define/undefine. BTW, including platform specific
headers and using -includeall usually causes problems as
you end up wrapping too much low level junk. You are
usually better off carefully selecting the headers that
provide the API you need and then wrap those.