- changed status to resolved
re-configure in a dirty build tree often does not apply new settings
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:
configure --some-incorrect-args
make
- completes successfully OR stops after GASNet build steps for any reason, including possibly the incorrect args
configure --corrected-args
(in the dirty build directory)make
- Observe that the original incorrect configure args are still in-force
- Specifically,
bld/*/gen_include/upcxx/upcxx_config.hpp
may contain stale values
- Specifically,
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.
Comments (1)
-
- Log in to comment
Resolve issue
#566This 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 ofconfigure
will not remain after it.→ <<cset c244f197689e>>