We haven't modified the compiler but instead plugged into it an external instrumentation tool using the compiler option `-toolexec`.
With this option, the compiler invokes every toolchain binary (compile, asm, link, etc.) through the provided program. So you can basically write a proxy program intercepting calls to `compile` to do source-code instrumentation, exactly like you would with go generate, but now automatically done during compilation on every package.
Something to note here is that everything is known and done statically in the source code. This could be addressed through metaprogramming if only the Go language had some ^^
We have similar needs at Sqreen but for security monitoring and protection reasons: we need to dynamically instrument functions at run time, while not asking any code modification to our users. To do so, we instead leverage the Go compiler to perform compile-time instrumentation that inserts hooks anywhere interesting. You can read more about this approach at https://blog.sqreen.com/dynamic-instrumentation-go/
cmake does not really offer the declarative interface I want (i.e. descriptions of components). It is still "low-level" and I would have to write cmake macros too. So I preferred native gnu make. Adding another tool on top of Make adds another layer of complexity, no matter how simple it is.
To me, the big benefit of cmake is its portability because it is able to generate visual studio files, eclipse files, etc.
Another one is that you end up with a static Makefile while my solution is dynamic: the makefile is evaluated at every execution (unless gnu make caches its parsed files but I don't think it does so far). It could be a problem for big projects like linux which would require a certain amount of parsing time of the Makefiles before evaluating them - while cmake or autotools, you go through this only once.
Over the last few years, I wrote a GNU Make library to make people able to write Makefiles in a very declarative way to help everyone in my company, me included, with this serious problem. I tried to make it as simple as possible using simple widespread concepts like UML components where you simply say a component has interfaces you can require and implementations you can link against. It is used to build our Operating System, our applications and even our reactjs web application.
It solved every problem I noticed about writing bare Makefiles: dependency tracking and generation is automated; the Makefile can be split into multiple sub-makefiles in your source-tree so that it matches your UML (these one http://agilemodeling.com/images/models/componentDiagramUML1.... you can perform out-of-source builds; generating complex software with deep dependency trees made simple (you inherit from other components' dependencies), etc.
I just embedded it on a PowerPC P2020DS processor as a baremetal program (using the newlib and by stubbing the syscalls) and it works, I get a baremetal javascript interpreter ;)
;){kind=link}
With this option, the compiler invokes every toolchain binary (compile, asm, link, etc.) through the provided program. So you can basically write a proxy program intercepting calls to `compile` to do source-code instrumentation, exactly like you would with go generate, but now automatically done during compilation on every package.