@eduarch42: Even though I like this idea, it has 2 main flaws:

First, not all softwares rely on git as their VCS, and not all of the git based projects are hosted on github/gitlab. If you want to build a drop-in solution, it should adapt to every solution out there.
A solution to that would be to use some kind of "driver" system, based on the protocol used to fetch a project: http://, ftp://, git://, gopher://, ...
It would hqve some corner cases, but could be more generic!

Second problem (which is huge IMO), is that there is no standard build system. And even out of all the build systems, all of them don't compile the same way.
From my experience, you cannot assume all makefiles have an "install" target for example. It means that you'll have to patch the makefile at some point, and for that, you need a way to keep track of your patches, and some kind of recipe to apply them.
The idea you propose (makepkg or global makefile) is how all package managers work already. They have an internal build recipe to create packages that the package manager can install/track.

Some other implementations try to "replace" completely any makefile, by providing a generic dropin build system: http://git.2f30.org/mkbuild/log.html
I love the idea but this looks too complex for me...

I went with a different approach myself, and decided to put the compilation process out of the package manager. You compile the software manually, install it in a chroot, and generate a tarball out of this chroot. this is your package, and the package manager can install it!
It leaves the user the possibility to use/create any automated build system he wants, and make use of an easy to understand and portable package format: a tarball.