compiler_wrapper portgroup

[Ryan Schmidt]

On May 7, 2021, at 12:13, Chris Jones wrote:

> Hi,
> 
> It solves a number of problems, but mostly it boils down to not all build systems or projects supporting the standard rules we use in macports for passing flags erc. to the underlying compilers. Legacy support PG for instance requires this to function and a number of ports, or a bunch of ports using a given build system, did not work with it. E.g.

Certainly the legacy support portgroup didn't used to require compiler wrappers...


> 1 The go based ports. I experimented for a long time trying to get them to work with legacy-support in the ‘standard’ way but in the end it just was not compatible with how this build system works. So I added a wrapper there, locally at first in the PG and with that all the go ports now build down to I think 10.7, whereas before it was limited to I think 10.12 and newer.
> 
> 2. Rust. Same deal as go. Now works down to 10.9.
> 
> 3. Bazel. This build system really goes out of its way to not allow you to modify its build environment. Again, wrapping the compilers in scripts which you then tell the build system to use is a great way to circumvent this.
> 
> 4. Finally, macports has support for ccache integrated, but it is a little hit and miss as to where it works. It didn’t work with bazel, but with the wrapper now will does. Similarly for all the python group ports, they also use the wrapper and as such work with ccache. If you have ever tried to work on ports like py-tensorflow or py-pytorch having ccache now working is a huge boost. Same for the makefile PG, it also now works with ccache.
> 
> So.. after implementing compiler wrappers in a number of places I decided it made sense to centralise it in one place.

Certainly MacPorts base could have used compiler wrappers from the beginning, either to add its flags or to implement its ccache and distcc support. I'm assuming there were reasons why it didn't, other than just nobody got around to doing it. I've thought about it before too, but there are problems with the approach. For example, your compiler wrappers use ccache if requested and include the legacy support flags if needed, but this means that when we look at a port's main.log or debug output, we won't see the word ccache or the legacy support flags so we won't know if they're present in the compiler wrapper or not; this could hinder debugging. (This is why we want ports to build with silent rules disabled: so that we can see the exact compiler invocations with all the args and environment variables.) Another problem is that some build systems inspect the compiler path. It's probably a bad idea for a build system to do that and it should be fixed, but if there are any build systems out there that check for example if the compiler path is exactly "/usr/bin/clang" and do something in response to that, then that would fail if the compiler path is your compiler wrapper.