default configure.cppflags

[Ryan Schmidt]

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:

http://gcc.gnu.org/onlinedocs/gcc/Directory-Options.html


> 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 patch is on this ticket:

https://trac.macports.org/ticket/40656


> 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? 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.