Improve gRPC patchfile handling

[ffoulkes]

• Define a "patchfile" property in the components file. Update components.py to support it.

• Provide three ways to determine the gRPC patch file:

  • Explicitly specified by the GRPC_PATCHFILE cmake variable (per the "patchfile" component property). This allows the patch file to be independent of the gRPC version number.

  • Implicitly derived from the GRPC_VERSION cmake variable (per the "version" component property). This provides backward compatibility with the current mechanism.

  • Implicitly specified by a grpc-current.patch.in symlink in the patches folder. This allows an outside process to apply the patch without knowing the gRPC version.

• Refactor patchfile handling into two functions:

  • define_grpc_patch_file(), which selects the template file to use.
  • define_grpc_patch_clause(), which generates the patchfile from the template and defines the patch clause.

• Make the path to the patch file explicitly relative to the top-level directory (CMAKE_SOURCE_DIR) rather than implicitly relative to grpc.cmake. This mitigates the "patch file not found" error in the MEV build.

• If we are unable to apply to apply the gRPC patch, the worst outcome is that the RUNPATH of the gRPC plugins won't be updated, and the user will have to set LD_LIBRARY_PATH. This is (a) suboptimal rather than fatal, and (b) moot because this version of the Stratum dependencies breaks RPATH anyway. Make the messages WARNINGs rather than FATAL_ERRORs.

• Correct the version number in the header comment of the gRPC v1.59.2 patch file.

[5abeel]

LGTM

[nupuruttarwar]

Do we plan to update the scripts for building dependencies to include the option of specifying GRPC_PATCHFILE ? Also, add documentation that it should be available in cmake/patches directory and on how to do it when building using cmake cmdline?

[ffoulkes]

Do we plan to update the scripts for building dependencies to include the option of specifying GRPC_PATCHFILE ? Also, add documentation that it should be available in cmake/patches directory and on how to do it when building using cmake cmdline?

No. GRPC_PATCHFILE is a static mechanism, not a dynamic mechanism. The maintainer defines the patchfile component property in components.json and then uses the components.py script to update deps.cmake. The patch step then uses the specified filename instead of deriving one from the gRPC version.

As I noted in my response to Sabeel, this variable is not intended to be set from the command line. It's a component property, like version (which cmake references as GRPC_VERSION).

[ffoulkes]

Also, add documentation that it should be available in cmake/patches directory and on how to do it when building using cmake cmdline?

@nupuruttarwar - Rereading your comment, I realized that I didn't really address your second question.

The existing documentation is in How to create a gRPC patch file.

To define GRPC_PATCHFILE, you add add a defines clause to the grpc entry in components.json:

    "grpc": {
        "name": "grpc",
        "url": "https://github.com/google/grpc.git",
        "sha": "883e5f76976b86afee87415dc67bde58d9b295a4",
        "tag": "v1.59.2",
        "version": "1.59.2",
        "defines": {
            "PATCHFILE": "custom.patch"
        }
    },

Then run components.py to update the deps.cmake file:

./scripts/components.py -o cmake/deps.cmake

Which produces the following:

set(GRPC_GIT_URL "https://github.com/google/grpc.git")
set(GRPC_GIT_TAG "883e5f76976b86afee87415dc67bde58d9b295a4") # v1.59.2
set(GRPC_VERSION "1.59.2")
set(GRPC_PATCHFILE "custom.patch")

I implemented the defines clause as general replacement for RECENT_PKGS and other ad hoc ways of handling special cases (especially in Protobuf, which has always been a problem child). See protobuf.cmake for examples of past and current workarounds.

We need documentation on components.json and the generator script. When time permits...