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.
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. Cheers Chris > On 7 May 2021, at 5:59 pm, Joshua Root <[email protected]> wrote: > > Recently, quite a lot of changes have been made to a number of portgroups, > eventually ending up with a new compiler_wrapper portgroup which is now > included by several others. > > Chris, for those who have not kept up with all the changes, would you be able > to explain what problems all this is solving, how it solves them, and why > this particular approach was chosen? > > - Josh
