extras/cannon Makefile should "just work" with OpenBLAS

[Dan Bonachea]

Right now the extras/cannon Makefile tries to figure out how to include/link BLAS and does a reasonable job for some standard BLAS setups.

It could be improved to additionally handle many common OpenBLAS installs, requiring the user to set at most one variable, with logic along the following lines:

ifneq ($(wildcard $(BLAS_INSTALL)/include),)
BLAS_HEADER_DIRS = -I$(BLAS_INSTALL)/include
else
ifneq ($(wildcard /usr/include/openblas/cblas.h),)
BLAS_HEADER_DIRS = -I/usr/include/openblas
endif
endif

ifneq ($(wildcard $(BLAS_INSTALL)/lib/libopenblas.{a,so}),)
BLAS_LDFLAGS += -L$(BLAS_INSTALL)/lib -lopenblas
else
ifneq ($(wildcard $(BLAS_INSTALL)/lib/libopenblas64.{a,so}),)
BLAS_LDFLAGS += -L$(BLAS_INSTALL)/lib -lopenblas64
endif
endif

[Paul Hargrove]

The snippet above looks to me sufficient to "just work" only for user builds and RedHat-based distributions, including CentoOS, Scientific Linux (Dirac) and OpenSuSE (Cori), where BLAS_INSTALL=/usr selects the distro-provided installation.

Ubuntu uses /usr/include/[system-tuple]/ where the system-tuple is something like powerpc64le-linux-gnu. This appears to be to allow inline ASM in headers. It can be queried using dpkg-architecture -q DEB_TARGET_GNU_TYPE. That is a script using CC in the spirit of config.guess and thus "just works" for CC set to a gcc cross compiler, but for a native PGI it "whines" and falls back to CC=/usr/bin/cc. So, this might not amenable to robust automation.

[Paul Hargrove]

Proposed solution in upcxx-extras pull request 23

[Paul Hargrove]

Resolved via the pull request noted previously.