Allow applying patches outside from git or skipping them entirely

[th0ma7]

TL;DR;

Using 140 branch, is it possible to avoid using git when applying patches (i.e. using source tar-balls)? Or is there an option to entirely skip the patching process (assuming I could easily apply patches using my build framework).

Longer version

I'm maintaining ffmpeg package for the SynoCommunity where we cross-compile open-source packages for Synology NAS. My goal is to enable --opencl in order for it to use NAS built-in GPU thru opencl such as when using apollolake processors or similar (ref: https://github.com/SynoCommunity/spksrc/wiki/Architecture-per-Synology-model).

I was able to cross-compile latest version 18.1 of intel-opencl-clang succesfully using our spksrc framework and Synology toolchains for their DSM v7.1 and v7.2 version of the NAS linux OS (which uses gcc-8.5 and gcc-12.2 respectively). WIP PR https://github.com/SynoCommunity/spksrc/pull/6158. Note that github-action is not trigerred as no association with ffmpeg is yet applied as still missing the igc portion - although local testing builds-out ok.

While further reading the HOWTO relatively to igc along with inspiration from arch-linux build process https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=intel-graphics-compiler-git it occurred that I need to use llvm-14.0.5 in order for igc to build sucessfully (along with SPIRV-LLVM-Translator and opencl-clang matching branch version 140, ref.: https://github.com/intel/intel-graphics-compiler/blob/master/documentation/build_ubuntu.md#Revision-table).

Contrarerly to using latest 18.1, it hapens that branch 140 plays with git assuming that corresponding source files for clang are actually under their own git repositories. It occurs that git cloning llvm repository is both space hungry and takes a really long while to proceed in contrary to using existing sources in tar.gz (further when testing-things up where many trials and errors occurs). Similarly, I usually download .tar.gz from needed github branches or referring to specific git hash commits instead of relying on git clone, mainly for reproducibility of builds (i.e. such as wget https://github.com/intel/opencl-clang/archive/ocl-open-140.tar.gz)

It turns out that intel-opencl-clang-140 ends-up screwing my own WIP branch within spksrc framework thru its various git calls when attempting to check for existing hash commits of clang in sight for patching.

Using our framework its easy enough to pre-apply the patches (i.e. located under opencl-clang/patches/clang). Question are:

1. is there a CMAKE variable to tell the build process that I'm using a source tar.gz and not a git repository (as there isn't any auto-detection process)?
2. or to simply skip the patching process?
3. or how could I change the cmake rule files to skip that process entirely?

Help much appreciated, thnx in advance!

[haonanya]

Hi, @th0ma7, yes, we will skip the patching process if it's not a git repo. Drafted https://github.com/intel/opencl-clang/pull/539.

[th0ma7]

@haonanya great! this is really much appreciated. Note that I noticed igc is behaving the same way and applies patches over llvm also calling git. Similar PR would probably be beneficial there as well. Again much thnx in advance.

[th0ma7]

@haonanya it still fails with the patched version (new PR using LLVM 14.x https://github.com/SynoCommunity/spksrc/pull/6166)

A subsequent build attempt would then work due to the prior build process switching my active tree to a new branch called ocl-open-140 leading that second to sucesfully skip the patching and build ok.

More detailed output available here: https://github.com/intel/opencl-clang/pull/539#issuecomment-2207790950

[th0ma7]

Solution tested sucesfully https://github.com/intel/opencl-clang/pull/545#issuecomment-2211764610

Pending merge to close issue.

[th0ma7]

closing as now fixed, thnx a lot!