Persist Chromium Patch Using automate-git.py

[leeroy]

We're attempting to apply a patch to the Chromium source code to work around the following issue:

viewtopic.php?f=6&t=19607&hilit=patch
https://github.com/chromiumembedded/cef/issues/2609

However, we're encountering an issue: after downloading the source and applying the patch, it doesn't seem to be retained. When we execute the following command:

Code: Select all

python3 automate\automate-git.py --download-dir=c:\code\chromium_git --depot-tools-dir=c:\code\depot_tools --force-clean --minimal-distrib --client-distrib --x64-build --with-pgo-profiles --branch=6167


the changes don't persist. It looks like there was not an interest to add a patch like this to CEF. Our workaround was to directly patch the relevant file (media/base/user_input_monitor_win.cc) and then build, but this approach unexpectedly erases the changes we made to the original file.

Could you advise us on whether there's a specific flag we need to include, or a different method we should adopt, to ensure our changes remain after the build process?

Thank you!

[magreenblatt]

You should create a fork of the CEF repo and commit your changes as a patch file. Then pass your fork URL (--url parameter) to automate-git.py.

[leeroy]

Interesting. Thank you!

[leeroy]

That works thank you! Though I'm hesitant to maintain a separate fork for this unique situation. I'm contemplating whether it would be feasible to propose a feature request. Specifically, I'm considering the addition of this functionality as a lifecycle component within 'automate-git.py', or perhaps as an option/flag for a custom patch. What are your thoughts on this approach?

Ideally I would like OnPreKeyEvent to trap windows keys and block them, but maybe that is simply not possible without the low level keyboard hook.

[magreenblatt]

Specifically, I'm considering the addition of this functionality as a lifecycle component within 'automate-git.py', or perhaps as an option/flag for a custom patch. What are your thoughts on this approach?

You're likely to need a new/updated patch for each CEF/Chromium branch, and managing those patches external to the CEF checkout may cause you difficulty over time. However, you can make custom modifications to automate-git.py if that's easier for you. It already has an apply_patch function that you can use.

[leeroy]

Specifically, I'm considering the addition of this functionality as a lifecycle component within 'automate-git.py', or perhaps as an option/flag for a custom patch. What are your thoughts on this approach?

You're likely to need a new/updated patch for each CEF/Chromium branch, and managing those patches external to the CEF checkout may cause you difficulty over time. However, you can make custom modifications to automate-git.py if that's easier for you. It already has an apply_patch function that you can use.

We plan to examine the 'apply_patch' function more closely. As of now, the entire process is automated on a substantial EC2 instance, and the setup is discarded once we've obtained our artifacts. Ideally, our goal is to execute 'automate-git.py build'. However, we want to integrate a code modification either before initiating this build command or within the build process itself. This modification aims to separate our changes from mainline CEF, without resorting to creating and maintaining our own fork.

[ndesktop]

You might also integrate into your build script the patching between sources step and the build step, something like

automate-git.py ... --no-build
cd chromium/src/cef
cef_create_projects
cd ..
do the custom patch
ninja -C <target1>
ninja -C <target2>
...

automate-git.py --no-build --no[anything non-distrib] --client-distrib
(or any other form of distrib)

Alternatively, you can maintain a fork of automate-git.py accepting some form of --external-patch parameter, and execute it before the "# Build CEF" section.