Opened 7 years ago

Last modified 6 years ago

#44413 new enhancement

Use a compiler wrapper script

Reported by: ryandesign (Ryan Schmidt) Owned by: macports-tickets@…
Priority: Normal Milestone:
Component: base Version:
Keywords: Cc: cooljeanius (Eric Gallager), larryv (Lawrence Velázquez)


I want to try to create a branch of MacPorts to use a compiler wrapper. This was suggested by a Qt developer and has also been mentioned within the MacPorts community before, e.g. in 2011 and in 2012.

Such a wrapper script would itself call the compiler, and add flags like -isystem${prefix}/include and -L${prefix}/lib to the end of the invocation. This would eliminate the need to manually do so in many portfiles that do not use standard build systems.

The wrapper script could remove any existing -L${prefix}/lib from earlier in the line, thus preventing problems resulting from -L${prefix}/lib appearing before local directories in the linker invocation (such as problems building a port when another particular port is installed), thus eliminating the need to laboriously fix each port's build system or use the conflicts_build workaround.

There should be no similar problem with a too-early -I${prefix}/include since the addition of -isystem${prefix}/include anywhere in the line should cancel that out.

The wrapper script could employ ccache and/or distcc if requested via the user's selections in macports.conf, eliminating the problem we have had to patch in some ports which didn't expect $CC to contain a space (see #15772), and allowing ports that currently have to be manually told how to use the right compiler to automatically use ccache and/or distcc without further work by the maintainer.

To automatically handle build systems that call "gcc" or "g++" (or "cc" or "c++", or "clang" or "clang++") directly, without using the $CC or $CXX variables—or even those that call $CC and $CXX but have a deficient or missing configure phase and currently have to be told how to use the right compiler—we could add the compiler's symlink directory to the $PATH.

Some build systems look at the compiler executable name to decide what to do, so I propose the filename of the wrapper script (or symlink thereto) be "clang" and "clang++" for clang, and "gcc" and "g++" for gcc. Additionally, "cc" and "c++" symlinks should be added for all compilers.

As an example, I propose a separate wrapper script (or separate symlinks to a single wrapper script) in a layout like the following layout:


Initially I will make a separate macports-compiler-wrappers port to install these symlinks, but later each compiler port might provide them directly.

I am hoping that the number of new problems such a wrapper script might cause will be far fewer than the number of old problems it magically fixes.

Change History (4)

comment:1 Changed 7 years ago by ryandesign (Ryan Schmidt)

Added macports-compiler-wrappers in my users directory in r122587. It's not done yet.

comment:2 Changed 7 years ago by cooljeanius (Eric Gallager)

We could use the macports-compiler-wrappers port to implement the Xcode plugins required for #40762

This port also seems like a good place to put Akim Demaille's g++-libc++ script:

comment:3 Changed 7 years ago by cooljeanius (Eric Gallager)

Cc: egall@… added

Cc Me!

comment:4 Changed 6 years ago by larryv (Lawrence Velázquez)

Cc: larryv@… added

Cc Me!

Note: See TracTickets for help on using tickets.