re-configure in a dirty build tree often does not apply new settings

[Dan Bonachea]

When a UPC++ configure is followed by a make that either completes or stops after the GASNet build steps (e.g. failing due to a problem with the UPC++-level configure arguments), a subsequent configure with modified inputs in the same (dirty) build directory will not always correctly apply the new configure settings.

Steps to reproduce:

1. configure --some-incorrect-args
2. make
   • completes successfully OR stops after GASNet build steps for any reason, including possibly the incorrect args
3. configure --corrected-args (in the dirty build directory)
4. make
5. Observe that the original incorrect configure args are still in-force
   • Specifically, bld/*/gen_include/upcxx/upcxx_config.hpp may contain stale values

This defect unfortunately means that users iterating towards a proper set of UPC++ configure arguments might not be testing what they think they are testing after the second and subsequent configures in a dirty build directory.

The recommended workaround is to ensure a fresh build directory before every invocation of configure (i.e. between steps 2 and 3 above). For out-of-place builds this means starting over with configure in a fresh/empty build directory. For in-place builds, this means starting over with configure on a freshly unpacked copy of the source archive.

[Paul Hargrove]

Resolve issue #566

This commit resolves issue #566 "re-configure in a dirty build tree often does not apply new settings" by ensuring that headers generated prior to a given run of configure will not remain after it.

→ <<cset c244f197689e>>