Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow applying patches outside from git or skipping them entirely #538

Closed
th0ma7 opened this issue Jul 3, 2024 · 5 comments
Closed

Allow applying patches outside from git or skipping them entirely #538

th0ma7 opened this issue Jul 3, 2024 · 5 comments

Comments

@th0ma7
Copy link

th0ma7 commented Jul 3, 2024

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 SynoCommunity/spksrc#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
Copy link

haonanya commented Jul 3, 2024

Hi, @th0ma7, yes, we will skip the patching process if it's not a git repo.
Drafted #539.

@th0ma7
Copy link
Author

th0ma7 commented Jul 3, 2024

@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
Copy link
Author

th0ma7 commented Jul 4, 2024

@haonanya it still fails with the patched version (new PR using LLVM 14.x SynoCommunity/spksrc#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: #539 (comment)

@th0ma7
Copy link
Author

th0ma7 commented Jul 6, 2024

Solution tested sucesfully #545 (comment)

Pending merge to close issue.

@th0ma7
Copy link
Author

th0ma7 commented Jul 9, 2024

closing as now fixed, thnx a lot!

@th0ma7 th0ma7 closed this as completed Jul 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants