On Oct 15, 2012, at 5:34 AM, Ryan Schmidt <ryandes...@macports.org> wrote:
> On Oct 15, 2012, at 07:16, Titus von Boxberg wrote: > >> Am 15.10.2012 13:47, schrieb Ryan Schmidt: >>> >>> I agree generally with what jmr wrote earlier: any port not respecting the >>> value of configure.compiler should be made to do so. That will solve the >>> problem. >> >> Would that solve the apr issue? >> >> I thought that the problem was caused by the buildbot >> having installed an older Xcode than my computer. >> >> When I run port -v configure apr on my machine it says >> "checking how to run the C preprocessor... /usr/bin/clang -E" >> >> So apr does seem to respect the value of configure.compiler? > > apr does respect configure.compiler, but it bakes the discovered value into > its apr-config script, which other programs, like serf1, then later use to > determine the compiler. So it is serf1 and maybe other ports that use apr > that need to be fixed to respect configure.compiler. I wouldn't say serf1, or any other port, is broken by trusting apr-config's compiler, that should be a correct value. Fixing it in serf1 isn't the real fix either. It's one thing for us to modify serf1, but people that have closed source, commercial code, like I do, that compiles and links against apr shouldn't need to fix or change apr-config's results, it should be a good value. So I like the idea of post-activate tweaking apr-config, it solves all of the issues (that I'm aware of). Blair _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
