-
Notifications
You must be signed in to change notification settings - Fork 68
GSoC 2021 Project ideas
Fortran Standard Library (stdlib)
Related issues:
- stdlib#69: String handling routines
-
stdlib#241: Include a
split
function (202X feature) - stdlib#268: Proposal for lists of strings
Prior work:
- iso_varying_string (functional string handling)
- implementation by Rich Townsend
- implementation by Brad Richardson
- implementation by J.L. Schonfelder
- ftlString with Python string like API
- StringiFor object-oriented string manipulation
- M_strings procedural / functional string manipulation
- and more, see stdlib#69
WIP:
- stdlib#269, stdlib#311: String list
-
fortran202x_split: Implementation of the
split
instrinsic for Fortran 202x
Mentors: Brad Richardson (@everythingfunctional)
Potential related issues:
Mentors: Arjen Markus (@arjenmarkus)
Cross-platform solution for file system operations.
Related issues:
- stdlib#201: File system operations
- stdlib#220: API for file system operations, directory manipulation
WIP implementation:
Cross-platform solution to abstract POSIX and Windows API for creating subprocesses.
Related issues:
- stdlib#22: Interface to POSIX I/O API
- stdlib#308: Subprocesses and Multiprocessing
Discourse thread:
Fortran Package Manager (fpm)
Provide the infrastructure to support a (local) package registry with fpm for managing dependencies.
- define the manifest syntax to use dependencies from a registry
- implement support for looking up and loading a (local) registry
- allow fpm to manage a local registry by fetching it from a remote registry
Related issues:
Mentors: Laurence Kedward (@lkedward)
Aim of this project is to implement version constraint resolution in the dependency tree of an fpm project.
Libraries:
-
libsolv:
interface via
iso_c_binding
as separate fpm package
Different version matching syntax available:
Add support for custom compile profiles. Define manifest syntax for declaring different build profiles (potentially for different compilers). Compiler arguments divided in project-wide compile arguments, inherited link arguments and global compile arguments (maybe more variants needed?).
Related issues:
- fpm#112: Thread about managing flags
- fpm#223: Compiler support and recognizion
- fpm#350: Proposal for manifest syntax
Mentors: Laurence Kedward (@lkedward), Ondrej Certik (@certik), Brad Richardson (@everythingfunctional)
Support for preprocessors which are not built-in to the compiler should be provided by fpm. A manifest syntax should be developed and implemented as additional (optional) step in the fpm build backend.
The package manifest preferably allows to:
- quickly select established preprocessors (fypp, fpp, ...)
- define preprocessor variables in a preprocessor independent way
- define a custom preprocessor
- select the file suffixes to be preprocessed
Selection of preprocessing should happen on per project basis, i.e. multiple preprocessors might be required. The preprocessor is usually external to fpm and fpm must be able to report useful errors for missing preprocessors.
Related issues:
- fpm#78: support for third-party preprocessors (e.g. fypp)
- fpm#308: Fortran-based smart code generation in fpm
Mentors: Laurence Kedward (@lkedward)
Aim of this project is it to create a manifest specification to provide defaults to executable targets in fpm projects. Information can be passed as environment variables, command line arguments or as runner.
- programs should have a way to find resources of which the relative position within the project source directory is known
- the current binary directory to access other targets within a project
- default runners like mpirun/cafrun or scripts from test frameworks should be usable to launch programs
- a general syntax to define environment variables and command line arguments should be defined
Some features should be implemented directly in fpm, while more elaborated functionality could be implemented in a separate fpm package as offical fortran-lang fpm package.
Mentors: Sebastian Ehlert (@awvwgk), Brad Richardson (@everythingfunctional)
Related issues:
- fpm#179: Testing with fpm test
Related discussions:
- fpm#328: Example which requires external data
Aim of this project is to enable fpm to create source code distributions of itself that can be bootstrapped without fpm.
- allow fpm to generate source code distributions with non-fpm build systems
- generated source code distribution should allow to build fpm project without fpm, git or internet access
- potential third-party build systems are CMake and meson
- allows easier distribution and packaging of fpm via various packaging ecosystems
Mentors: Sebastian Ehlert (@awvwgk)
Related issues:
Aim is to provide an fpm package or a functionality in fpm to check for standard conformance of a compiler.
Prior work:
Mentors: Damian Rouson (@rouson), Arjen Markus (@arjenmarkus)
- check and organize the issue tracker
- sort and review pull request
- ping pull request authors and merge patches
Mentors: Brad Richardson (@everythingfunctional)
- extract meta data from fpm.toml file instead of FORD project file
Mentors: Sebastian Ehlert (@awvwgk)