Fortran-FOSS-Programmers / Fortran-FOSS-Programmers/FLATPack-defunct

Proposed installation management

Open
#7 5 comments 0 reactions 0 assignees View on GitHub
Dominant language
Python
Stars
7
Forks
1
PR merge metrics
No merged PRs in 30d

Description

Hi all, I just want to elaborate more on how I suggest managing multiple compilers and installed packages. As you all know there is no standard Fortran ABI, and on many systems it is critical to support multiple Fortran compilers. `.mod` files can even be incompatible between different releases from the same compiler vendor. Often users then want to build their own programs against libraries that are installed. FLATPack should make it easy for users to link against and `use` Fortran packages managed by FLATPack.

I think FLATPack needs to know about compilers installed on the system via some configuration file, and optionally how to activate them. For example some DoD HPCs use GNU Modules to activate different compilers. Also, there may be MPI compiler wrapper scripts etc. A configuration file will be needed to tell FLATPack which compilers are available and how to use/activate them.

A method like

> **activate** [.]

can be used to make available all packages installed on the system on standard compiler search paths. That way users only need to add a line like `-ljsonfortran` and the compiler can find `libjsonfortran.a` and `json_module.mod` since the proper versions of the files have been symlinked into compiler search paths by the **activate** method, and any previously activated packages from other compilers are unlinked.

```
$ tree \
# This would be something like /usr/local/ or ~/
└── FLATPack # other FLATPack code could live in subdirectories, like Homebrew
├── formulae # holds python snippets containing build instructions kept under git version control
└── packages
├── Intel
│   └── 16.0.0
│   ├── deployed # Components of activated packages are linked into here
│   │   ├── bin
│   │   ├── include
│   │   ├── lib
│   │   └── share
│   └── json-fortran
│   └── 4.1.1
│   ├── bin
│   ├── include
│   ├── lib
│   └── share
├── NAG
├── PGI
└── gfortran
├── 4.9.2
│   ├── deployed # Components of activated packages are linked into here
│   │   ├── bin
│   │   ├── include
│   │   ├── lib
│   │   └── share
│   └── json-fortran
│   └── 4.1.1
│   ├── bin
│   ├── include
│   ├── lib
│   └── share
└── 5.1.0
├── deployed # Components of activated packages are linked into here
│   ├── bin
│   ├── include
│   ├── lib
│   └── share
└── json-fortran
└── 4.1.1
├── bin
├── include
├── lib
└── share
```

the **activate** method will first unlink all entries in `/usr/local/{bin,lib,include,share}` pointing to matching entries in the currently activated compiler’s `deployed` directory. It will then link each item in the requested compiler’s `deployed` directory into `/usr/local/…`

When building a new package the build can be performed with each compiler available on the system which the package has instructions for in its formula. This way the user can manage which compiler is currently active, and which packages and which versions of the packages are currently active.

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.