Compilers and Variants and Architectures Oh My!

Ryan Schmidt ryandesign at
Mon Mar 25 14:51:22 PDT 2013

On Mar 24, 2013, at 18:35, Lawrence Velázquez wrote:

>> Would it indeed be wise to install clang 3.2 or 3.3
> You can certainly install any compiler port and use it to build
> individual ports. You can do this by setting configure.compiler on the
> command line.
>    sudo port install foo configure.compiler=macports-clang-3.2
> The valid values for configure.compiler are listed in
> UsingTheRightCompiler.

Setting configure.compiler on the command line is intended for testing purposes, as a means for discovering what happens with different compilers, with the ultimate goal of updating the portfile's compiler selection. It's not intended for regular use during the normal course of installing ports. Probably the vast majority of ports are not tested with non-default compilers, so you may run into additional problems that nobody has seen before. And setting configure.compiler on the command line completely overrides the portfile's compiler choice, *including* compiler.blacklist. So even if a portfile author has already indicated that a port will not work with that compiler, by setting it on the command line, you'll be trying to use it anyway. Best case, the port will fail to build; worst case, the build might succeed but have runtime errors. I would like for MacPorts base to at least print a warning when you ask for a compiler that a port has already blacklisted, but it does not currently do this.

>> If so, how does one set the default compiler in MacPorts?
> MacPorts will read "default_compiler" from macports.conf, but this is
> unsupported, and I really do not recommend using this. It should not be
> necessary and would be suboptimal for us because it would mask build
> issues with Xcode's compilers. We'd prefer to fix ports so that they
> build correctly on as many OS X versions as possible, without any manual
> compiler selection; if you encounter problems using a particular
> compiler to build a particular port, please file a ticket.

*If* you want to override the default compiler always, then setting default_compiler in macports.conf is best, since it will respect any blacklists or whitelists specified in ports. However, again, because most users and developers don't test with non-default compilers, it's possible that you'll encounter errors we haven't seen before. For example, portfile authors might have discovered that a port does not build with clang, and so they might blacklist "clang", but that would only cover the clang that comes with Xcode, and MacPorts clang compilers, though they would also not work for this hypothetical port, would still be allowed, and would then fail. Yes we should be fixing these problems in the ports (ideally by fixing the build with clang, or at least by properly blacklisting all the clang versions that won't work) but by changing your default compiler you may be signing yourself up for a disproportionate amount of work in reporting these problems to us. MacPorts 2.2 will make it easier for portfile authors to blacklist all versions of a compiler.

More information about the macports-users mailing list