On Oct 15, 2012, at 08:21, Blair Zajac wrote: > On Oct 15, 2012, at 5:34 AM, Ryan Schmidt wrote: > >> 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.
They are broken, though. We expect portfile authors to be able to specify configure.compiler and to have the build system respect that. As of MacPorts 2.1 I think I remember hearing that we also expect users to be able to specify the compiler by editing macports.conf. Neither of these things work when software asks some other piece of software's config script what compiler to use. > 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). We can do that. I just don't understand for what purpose apr installs a program that offers information about what compiler was used. It's not apr's business to do that. Or I would say no other program should care what compiler apr was compiled with. _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
