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.
_______________________________________________
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
