No, leave it as it is. I don't want colorization and I certainly don't want the screen to clear when I'm done. That's so annoying. I want more's remnants left on the screen after exiting so I can refer back to it.

No, leave it as it is. I don't want colorization and I certainly don't want the screen to clear when I'm done. That's so annoying. I want more's remnants left on the screen after exiting so I can refer back to it.

Ahh, thanks for the clarification re src builds and turning off /usr/include. WRT ports, I meant to turn on including /usr/${LOCALBASE} for port builds first, see what the fallouts are and address/fix the issues, then turn it on for base CC. But since I was under the wrong impression with regard to building src, I withdraw my comment about applying the change to port builds first before base CC. Sorry for the noise :-(

It's not clear to me how this proposed change (option 1) would affect building base from source. It seems we would want a way to turn off /usr/local/{include,lib} when building src, probably off by default. It seems option 1 precludes turning it off for source builds.

I'd rather have compilers built out of ports include /usr/${LOCALBASE}/include and base's CC (clang, gcc, whatever) not include /usr/${LOCALBASE}/include. Also, what about /usr/local/lib? It seems that including /usr/local/include is only part of the problem - you can compile but not link? If we think folks are savvy enough to add /usr/local/lib to their library path, but not savvy enough to add /usr/local/include to their include path, that seems to be in conflict.

I don't think 2 separate brace styles is necessary. style(9) already allows braces for a single statement on multiple lines, so you can always add a comment line to allow braces. If the statement is important, a comment might be warranted anyway.