[MacPorts] #44413: Use a compiler wrapper script

[MacPorts]

#44413: Use a compiler wrapper script
--------------------------+--------------------------------
 Reporter:  ryandesign@…  |      Owner:  macports-tickets@…
     Type:  enhancement   |     Status:  new
 Priority:  Normal        |  Milestone:
Component:  base          |    Version:
 Keywords:                |       Port:
--------------------------+--------------------------------
 I want to try to create a branch of MacPorts to use a compiler wrapper.
 This was [https://bugreports.qt-
 project.org/browse/QTBUG-34902?focusedCommentId=222528&page=com.atlassian.jira.plugin.system.issuetabpanels
 :comment-tabpanel#comment-222528 suggested by a Qt developer] and has also
 been mentioned within the MacPorts community before, e.g.
 [https://lists.macosforge.org/pipermail/macports-dev/2011-June/014911.html
 in 2011] and [https://lists.macosforge.org/pipermail/macports-
 dev/2012-October/020653.html 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 [UsingTheRightCompiler 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 [UsingTheRightCompiler 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:

 {{{
 ${prefix}/libexec/macports/compiler-wrappers/clang/bin/cc
 ${prefix}/libexec/macports/compiler-wrappers/clang/bin/c++
 ${prefix}/libexec/macports/compiler-wrappers/clang/bin/clang
 ${prefix}/libexec/macports/compiler-wrappers/clang/bin/clang++
 ${prefix}/libexec/macports/compiler-wrappers/macports-clang-3.3/bin/cc
 ${prefix}/libexec/macports/compiler-wrappers/macports-clang-3.3/bin/c++
 ${prefix}/libexec/macports/compiler-wrappers/macports-clang-3.3/bin/clang
 ${prefix}/libexec/macports/compiler-wrappers/macports-
 clang-3.3/bin/clang++
 ${prefix}/libexec/macports/compiler-wrappers/macports-gcc-4.8/bin/cc
 ${prefix}/libexec/macports/compiler-wrappers/macports-gcc-4.8/bin/c++
 ${prefix}/libexec/macports/compiler-wrappers/macports-gcc-4.8/bin/gcc
 ${prefix}/libexec/macports/compiler-wrappers/macports-gcc-4.8/bin/g++
 }}}

 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.

-- 
Ticket URL: <https://trac.macports.org/ticket/44413>
MacPorts <http://www.macports.org/>
Ports system for OS X