search

BerkeleyLab / caffeine

A parallel runtime library for Fortran compilers
https://berkeleylab.github.io/caffeine/
Other
37 stars 7 forks source link

Expand install.sh to allow passing configure options to GASNet #101

Open bonachea opened 5 months ago

bonachea commented 5 months ago

Currently install.sh configures GASNet-EX with only three hard-coded "customization points":

  1. C Compiler
  2. C++ compiler
  3. Install prefix

ie:

FC="$FC" CC="$CC" CXX="$CXX" ./configure --prefix "$PREFIX"

I'd consider these the "bare minimum" settings necessary to get a functional GASNet-EX install, and they happen to be sufficient for smp-conduit (no network) on most systems. However this implicitly instructs GASNet's configure to use the auto-detected defaults for all other settings, for which there are several hundred (see GASNet configure --help).

Distributed systems differ wildly in the details of available network hardware and especially job spawning, such that many real deployments with a network will require additional configure arguments to override the automatic defaults with system-appropriate settings to get a working/optimal GASNet install.

This issue is to request a mechanism for the command-line invocation of install.sh to pass configure arguments to the underlying GASNet configure. Options include:

  1. My recommendation would be the approach taken by UPC++ whereby any unrecognized command-line options to install.sh are passed-through unmodified to GASNet configure. This mimics the way that configure itself operates with sub-packages.
  2. Another (complementary) mechanism would be to define an envvar like $GASNET_CONFIGURE_ARGS that supplies a list of configure options for GASNet configure. UPC++'s installer also recognizes this variable for legacy reasons, but it can also be useful in some packaging scenarios where one needs to inject configure options without directly modifying a scripted invocation of install.sh.
ktras commented 5 months ago

I'm leaning towards option 2, since based on discussion with Dan in a meeting, option 2 is likely what we will want in the long term for integration into LLVM CMake build system.