Installing over an older install is broken

[Paul Hargrove]

UPC++ versions 2021.3.0 and newer install a single include/ and a per-library gen_include/, with the latter containing only the upcxx_config.hpp header. Meanwhile, older versions installed an entire distinct header tree for each library instance (see issue 299).

I have yet to reconstruct the exact steps necessary to reproduce, but I discover by accident that multiple "bleeding edge" and/or "nightly" builds have been installing to the same directory each night without removing the old one. This resulted in upcxx_config.hpp being located in two places, and unfortunately the older one occurs earlier in the include path.

In the case of these nightly builds the problem went unnoticed until after pull request 368 (resolving issue 487) renamed several identifiers defined in the config header. The result I saw was that even though the build completed and installed "correctly" use of the installed upcxx would fail with

 error: #error directive: "Invalid UPCXXI_MPSC_QUEUE_xxx."
        #error "Invalid UPCXXI_MPSC_QUEUE_xxx."
         ^

[Paul Hargrove]

There at least two work-arounds available to the user with write permission to the install directory:

If one is aware this issue before installing, one simply needs to remove the old install first.

If one becomes aware after the install, the following "surgical" repair can be used:

$rm -r $prefix/upcxx.*/include

where $prefix denotes the install prefix specified at configure or installation time.

Personally, I would recommend use of versioned directory names to avoid the conflict entirely.

[Paul Hargrove]

The reason the old per-library include/ appears in the include path at all is the following GNU Make expression used to generate the -I options in upcxx-meta.

$(addprefix -I, $(wildcard $(dir $(DST))include) $(wildcard $(DST)/include) $(DST)/gen_include)

The intent is to adapt correctly to the differences between the in-builddir and installed directory layouts. However, the in the case that the destination contains an installation of UPC++ prior to 2021.3.0 (prior to merge of pull request 333 if using develop) the second wildcard unexpectedly matches the old include/ and places it ahead of the gen_include/.

There are at least two options available to generate an installed upcxx-meta which would not erroneously place upcxx_config.hpp in the "legacy" directory ahead of the "current" one in the include path.

1. Reorder the existing expression to place gen_include first. This results in the legacy header being last, but does not remove it entirely.
2. Adopt more complex logic which "branches" on in-build tree versus installed to generate the single correct include rather than assuming that exactly one of two wildcard expressions will match.

Additionally, one could modify the install rules to remove the legacy directory or to detect it and refuse to install until/unless the user removes (or renames) it. IMO the latter sounds safer if we want to pursue detection of old installs at all.