WIP: POC patch mechanism

[drodin]

• I've checked this Git style guide. [Yes]
• I've checked this CMake style guide. [Yes]
• My change will work with CMake 3.2 (minimum requirement for Hunter). [Yes]
• I will try to keep this pull request as small as possible and will try not to mix unrelated features. [Yes]

Just a POC of a patch mechanism which was discussed many times: #28 #255 etc.

This is a minimal change which doesn't break anything.
All logic is directory/file based: search PROJECT_NAME/patches/PROJECT_VERSION folder for file CMakeLists.txt, directory cmake and copy them to project source folder, apply *.patch files if they are found.

Example conversion of libmad (non CMake, source forge based) from vcpkg with some changes for installation:
from: https://github.com/microsoft/vcpkg/tree/030cfaa24de9ea1bbf0a4d9c615ce7312ba77af1/ports/libmad
to: drodin@0cfad8a
tests: https://github.com/drodin/hunter/runs/2972493798

---

[rbsheth]

OMG yes please @drodin! Let me know if I can help.

[drodin]

@rbsheth Had time to think about it, and found a major downside:
There is no 'internal' patch command in cmake, and probably this won't be fixed https://gitlab.kitware.com/cmake/cmake/-/issues/16854
So to implement a patch mechanism, we would have to introduce another dependency for Hunter: git or patch utility (seems later is taken from git package on windows anyway).

[Thalhammer]

I'd like to revive this, since the requirement to have a fork of every supported package really makes adding new packages a lot harder and not user friendly.

I have two notes on this:

• The need for copying CMakeLists.txt and the cmake folder is not needed since patch files can in fact create and delete files (See below for an example diff)
• I think it is safe to assume that any system that would be used to compile source code has some sort of patch command installed

So instead of having an entire directory with multiple patch files and CMakelists per version I propose using a single PROJECT_NAME/patches/<VERSION>.patch that contains all the changes necessary. Given that those might get pretty large and should be immutable (just like the release packages) we could put them into a separate repository outside of the main hunter tree if thats a concern and then download them just like the release package.

Another concern is the reduced ability to quickly view the changes made by a patch. I dont have a solution for that one, but worst case you could fork the original project, apply the patch and push it to your fork.

One important thing this should help with is non git packages. Currently its practically a requirement for packages to live on github which, especially for older packages is often not the case.