default configure.cppflags

[Daniel J. Luke]

On Oct 2, 2013, at 8:55 PM, Ryan Schmidt <ryandesign at macports.org> wrote:
> On Oct 2, 2013, at 19:29, Daniel J. Luke wrote:
>>> But another way to handle that issue is to replace "`-I${prefix}/include`" with "`-isystem${prefix}/include`", and several ports (like freetype, ghostscript and pianobar) do that. Which brings up the question of whether we should change MacPorts' default configure.cppflags to that. Would there be any harm?
>> 
>> where is -isystem documented?
> 
> I found it in the gcc documentation in the same place where -I is documented:

ok, I was looking for it in clang docs and didn't find it ...

>> If it does what it looks like it does, it could possibly cause issues depending on what is in ${prefix}/include (ie, if there's some header that would override a system header).
> 
> What it does is append the given directory after all -I directories. Also, if an -isystem directory is also specified with -I, the -I for that directory is ignored. So in this way I think it's exactly what we want. From what I've read, -isystem should be used for system and third party library headers, and -I should be used for paths within your project's own source code. I've made the change locally and I'll try it out for awhile and see what happens.

the gcc manpage indicates that there's some extra magic ("Mark it as a system directory, so that it gets the same special treatment as is applied to the standard system directories.") that may or may not be what we want in this case too, although I'm not sure what that actually does.

>> Actually, even -I${prefix}/include is too big of a stick since builds pick up installed ports even if they shouldn't (which is why, way back in the mists of time, we didn't set that by default). Hopefully some version of sandboxing/trace mode will eventually fix this (so that only files belonging to ports that are listed as dependencies appear as if they exist to software that's being built).
> 
> You mean opportunistic linking?

no, but the corresponding problem with includes.

> We also put -L${prefix}/lib in LDFLAGS and set CPATH and LIBRARY_PATH; they all contribute to opportunistic linking. Changing -I to -isystem isn't meant to address this problem.


I wasn't implying that it was - just that (depending on gcc's implementation) there's the possibility that this change would cause similar issues (stuff from other installed ports being selected preferentially before system-supplied headers). Maybe the -I we already use also does this, so it's not introducing any additional issues, though.

--
Daniel J. Luke                                                                   
+========================================================+                        
| *---------------- dluke at geeklair.net ----------------* |                          
| *-------------- http://www.geeklair.net -------------* |                          
+========================================================+                        
|   Opinions expressed are mine and do not necessarily   |                          
|          reflect the opinions of my employer.          |                          
+========================================================+