Improve configure behavior for GASNet archives lacking Bootstrap
The following error message briefly confused me, and is likely to be inscrutable to an end user:
$ ../upcxx/configure --with-gasnet=https://bitbucket.org/berkeleylab/gasnet/get/develop.tar.gz
Fetching https://bitbucket.org/berkeleylab/gasnet/get/develop.tar.gz
Unpacking /home/pcp1/bonachea/UPC/bxx-develop/bld/develop.tar.gz
GASNET='https://bitbucket.org/berkeleylab/gasnet/get/develop.tar.gz' does not appear to contain GASNet
The problem here is UPC++ configure does not support URLs to an auto-vivified GASNet archive or otherwise unBootstrapped GEX source tree. However we don't appear to document this requirement, so an end user attempting to fetch their own GASNet sources may get this wrong and have no idea how to remedy the problem.
It would be less confusing if that error message diagnosed this specific failure mode, eg "This appears to be a GASNet source archive or clone that is missing a Bootstrap operation".
Better yet, the script could attempt to execute Bootstrap
itself (thus adding support for auto-vivified archives). This feature upgrade would obviously require the presence of functional autotools, and (lacking those) should dump the error messages from Bootstrap to explain what happened and suggest using a Bootstrapped GASNet release archive.
Comments (5)
-
-
reporter - removed version
Removing version: mk-develop branch (automated comment)
-
- changed status to open
Proposed fix in pull request 319
-
configure: relax assumption on GASNet tarball
This commit modifies logic in
configure
to examine the GASNet tarball to determine its top-level directory, rather than assuming it matches the basename of the tarball.The majority of the diff is swapping of the logic which fetches a URL or verifies a path, with the logic to check for an existing destination. This reordering is required since we can no longer claim to know the destination prior to fetching the tarball.
This commit addresses Issue 442 "Improve configure behavior for GASNet archives lacking Bootstrap" such that the reported failure when given a BitBucket autovivified tarball URL now correctly reports as follows:
$ [...]/configure --with-gasnet=https://bitbucket.org/berkeleylab/gasnet/get/develop.tar.gz Fetching https://bitbucket.org/berkeleylab/gasnet/get/develop.tar.gz Unpacking develop.tar.gz GASNET='https://bitbucket.org/berkeleylab/gasnet/get/develop.tar.gz' appears to contain an un-bootstraped source tree. If you wish to use these sources, please unpack the archive, run './Bootstrap' in its top-level directory, and then re-run this configure passing '--with-gasnet=...' pointing at the unpacked sources.
Work to automate in-place Bootstrap of unpacked sources is NOT included in this commit.
→ <<cset 5daa3bb7ae4e>>
-
- changed status to resolved
configure: automate bootstrap of GASNet-EX sources
This commit adds logic in
configure
to run GASNet'sBootstrap
script when needed, rather than instructing the user to do so.Resolves issue 442
→ <<cset d74cea297f67>>
- Log in to comment
The root problem here is that the top-level dir in the tarball is
berkeleylab-gasnet-[sha1]/
. With the current logic, this would fail even if the tarball contained a bootstrapped GASNet-EX because our logic requires a match between the tarball filename and the directory it contains.In particular, the failing check is for
develop/gasnet.h
indevelop.tar.gz
. If not for the unexpected top-level directory name, this check would pass and a later existing check would explain the need to Bootstrap.TL;DR: current logic is making a rigid assumption about the tarball content, relaxing of which would be sufficient to fix the reported problem regarding an uninformative error by making an existing is-Bootstrapped check reachable. Addressing that assumption is also a prerequisite for possibly running
Bootstrap
.