RFE: mechanism to automate patching GASNet sources

[Paul Hargrove]

The UPC++ configure script typically uses either a GASNet tarball embedded in the UPC++ release, or downloads one, with the other supported option being an option to specify the path to an existing GASNet source tree.

In order to provide an end-user of UPC++ with a GASNet-EX patch to resolve a bug they are experiencing (or to test whether it fixes a bug), we have at least the following options:

1. Provide the user with a URL of a patched GASNet-EX tarball we prepare
2. Instruct user to download and patch GASNet-EX manually, passing --with-gasnet=[path-to-gasnet-src] to configure
3. Instruct user to manually patch the downloaded GASNet-EX (in bld/GASNet-[...]) after running configure (which unpacks the tarball).

None of those is "untenable", though option 1 seems like a poor choice.
This RFE is a proposal to provide an automated variant of option 3 in which configure applies the patches.

A proposed "spelling":

• --with-gasnet-patch=(URL|file|sha)[,...]

IOW: a configure argument providing a comma-delimited list of URLs, local files and git commit hashes.
The case of a commit hash would result in conversion to a URL which fetches the raw diff from the GASNet-EX git repository.

I would like this process to also "scribble on" the version.git in the GASNet-EX source tree, at least appending _dirty or similar.

[Dan Bonachea]

With this machinery in place, it shouldn't be too hard to additionally deploy --with-patch=(URL|file|sha)[,...] that applies patches to the UPC++ part of the repo (probably excluding configure itself and the scripts it invokes, for obvious reasons).

This would give us a mechanism to deploy UPC++ library source hotfixes to users of our source tarball without them needing to learn how to git clone a hotfix branch.

[Paul Hargrove]

I don't think that that automated patching of the UPC++ part is going to be easy.

The GASNet sources start pristine from a tarball at each and every run of configure, and thus one can easily discard the changed sources and start "fresh". However, with the UPC++ sources, users of a tarball (as opposed to git) would probably need to manually start over from unpacking a tarball if any patch fails to apply cleanly.

Additionally, each run of configure would have a lasting effect on the sources, making multiple runs employing --with-patch cumulative. That is not "principle of least surprise" IMO.

I think we'd need to consider providing the functionally to patch UPC++ via a script in utils/ rather than as an argument to configure. Doing so would allow patches to configure itself. When implementing the functionality for GASNet sources, I think we should consider putting most of the logic in a stand-alone script to enable reuse for patching UPC++ itself.

[Dan Bonachea]

Worth noting that once pull request #319 is merged, the user can select a hotfix branch or patch of GASNet that we provide (the most common type of patch) by simply passing configure --with-gasnet=https://bitbucket.org/berkeleylab/gasnet/get/COMMITHASH.tar.gz

So I agree this should perhaps be deferred until we see whether there is real demand to justify the work.