Repository: conan-io/conan

Issue:
C++11 and -isystem
Hello !

I am doing some tests with conan, CMake and Corss Compilation for ARM (with a custom CMake toolchain) under linux.

The thing is my code uses some C++11 header only library which is also a conan package. With that configuration, I am getting this kind of error messages with gcc : 

```
error: template with C linkage
```

After some investigation, I found that conan defined include paths as following : 

```
-isystem /package/include/path
```

And if I replace that by : 

```
-I/package/include/path
```

Everything compiles without any problem.

So my question is : what is the point of using "-isystem" instead of "-I" ?



Discussion:
Yes, it was something that was introduced because of users requests: it is typical that some libraries headers are not perfect and can show many warnings at build time, which are annoying for some developers, cause forking the library to fix those warnings would be too much. Using "system" for dependencies includes silently ignore such warnings.

What I not expected is such "system" definition to affect in that way and generate that error. Can you please point me to the code/package/example that can throw that error?

I guess you replaced it in conanbuildinfo.cmake, but the problem would be that next `conan install` will overwrite it, right? Thanks for reporting this issue.

Ok, I did not know what that option was for. Is sounds weird for me, I don't have this kind of warning with the libraries I use, but anyway.

I investigated a little more, and it seems like it is a gcc bug.
When I use : 
- arm-none-eabi-g++ (based on version 5.2.0)
- avr-gcc (based on version 4.9.3)
  I get this error.

But for my native gcc system (version 5.3.1), it is ok.

If you want the minimal code : 
https://drive.google.com/file/d/0B9V_NolZXjZ-Ni0wMGRJREFUbzg/view?usp=sharing
It is not a conan example (my example was too dirty to be published ^^), but you can see the error.
(nb: the arm compiler will never compile totally because of linker error, even with the example that "works", but it is not a problem, I was just too lazy to do a proper linkage...)

Maybe it is a problem of version ? I may try with native gcc 5.2 to see if it fails or not.

This seems to be caused by the behavior of -isystem
According to https://gcc.gnu.org/onlinedocs/cpp/System-Headers.html

> On very old systems, some of the pre-defined system header directories get even more special treatment. GNU C++ considers code in headers found in those directories to be surrounded by an extern "C" block.

Also this doesn't seem like the safest thing to do since it changes the search order of includes.

The guilty is in the generated cmake code: `include_directories(SYSTEM ${CONAN_INCLUDE_DIRS})` where the SYSTEM is hardcoded right now. Maybe it makes sense to make it opt-in for those who want to use its behavior? Or opt-out, as the default is the desired for the majority of users?

I would probably recommend opt-in since it has a few unexpected side effects.

Yes, make sense, lets go for that. 


Resolving patch:
diff --git a/conans/client/generators/cmake.py b/conans/client/generators/cmake.py
--- a/conans/client/generators/cmake.py
+++ b/conans/client/generators/cmake.py
@@ -84,7 +84,11 @@ def _aux_cmake_test_setup(self):
 endmacro()
 
 macro(conan_flags_setup)
-    include_directories(SYSTEM ${CONAN_INCLUDE_DIRS})
+    if(CONAN_SYSTEM_INCLUDES)
+        include_directories(SYSTEM ${CONAN_INCLUDE_DIRS})
+    else()
+        include_directories(${CONAN_INCLUDE_DIRS})
+    endif()
     link_directories(${CONAN_LIB_DIRS})
     add_definitions(${CONAN_DEFINES})
 


Test patch: