GSoC 2021 Project ideas

Introduction

Welcome to the Fortran-Lang ideas page for students applying for Google Summer of Code (GSoC). If you are student interested in applying for GSoC, see the Student instructions page for more information.

The list here is based on priorities identified by Fortran-Lang contributors and should inform students as to the state and direction of each project. If you are interested in an idea on this page, please contact us on our Discourse to ask any questions you have and get the latest information about the project idea. Make sure you have read the existing discussion(s) in any linked issues.

The project ideas on this page are grouped by parent repository; make sure you have familiarised yourself with each repository before exploring the ideas here.

Contents

• Fortran Package Manager (fpm)
  • Local package registry
  • Version constraint resolution
  • Preprocessor support
  • Handling compiler arguments
  • Extended Testing Support
  • Source Code Distribution with Foreign Build Systems
  • Standard Conformance Suite
• Fortran Standard Library (stdlib)
  • Strings
  • Containers
  • OS Integration: filesystem
  • OS Integration: subprocesses
• LFortran Compiler
• FORD
  • Maintenance of the FORD project
  • Use fpm package manifest as project file
• Submitting your own idea

Fortran Package Manager (fpm)

Local package registry

fpm currently supports decentralised package dependencies whereby dependencies are specified without a central registry. A long-term goal for Fortran-Lang is to host a community-supported registry of fpm packages and for fpm to support interfacing with this and other registries to simplify dependency management.

This project idea aims to acomplish a major step towards a central package registry by implementing support in fpm for a locally-hosted package registry. In particular, this project idea will entail:

• Defining the manifest syntax to use dependencies from a registry
• Implementing support for looking up and loading a (local) registry
• Allowing fpm to manage a local registry by fetching it from a remote registry

Related issues:

• fpm#321: Implement support for a local registry
• fpm#35: Full package registry

See also:

• fpm-registry: Prototype central registry
• fpm-search: fpm app for searching the registry for fpm packages

Mentors: Laurence Kedward (@lkedward), Milan Curcic (@milancurcic)

Version constraint resolution

The current decentralised package system in fpm allows dependencies to be fetched via a git repository url. As part of this, a git tag or commit can be given to require a specific version of a dependency. There is however no way of specifying version compatibility requirements (e.g. >= 1.0.0, <2.0.0) and no way to resolve many such requirements across a dependency tree.

This project idea will require:

• Defining a manifest syntax for version compatibility matching
• Implementing support in fpm for solving a set of version compatibility constraints

A possible approach will be to to interface with an existing satisfiability solver such as:

• libsolv: interface via iso_c_binding as separate fpm package

See also: existing options for version matching syntax:

• conda
• npm
• cargo

Handling compiler arguments

fpm currently has limited support for specifying the command line arguments supplied to the compiler and linker. This is an important functionality when compiling Fortran and C code and is a high-priority item for fpm. Once implemented this functionality also paves the way for supporting features such as OpenMP and MPI.

Compiler argument handling must account for:

• Different compilers (e.g. gfortran, ifort)
• Different build profiles (e.g. release, debug, custom)
• Different argument types (e.g. link-time, local-project, project-wide, ...)

This project idea will require:

• Implementing manifest syntax for abstracting common compiler options (e.g. fast-math)
• Implementing manifest syntax for manually specifying compiler flags for different build profiles / different compilers
• Implementing logic for how compiler arguments propagate between dependencies

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)

Preprocessor support

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)

Extended Testing Support

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

Source Code Distribution with Foreign Build Systems

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:

• fpm#69: Have CMake and Make backends
• fpm#70: Have a Conda backend

Standard Conformance Suite

Aim is to provide an fpm package or a functionality in fpm to check for standard conformance of a compiler.

Prior work:

• fortran-compiler-tests
• flibs chkfeatures
• Defunct

Mentors: Damian Rouson (@rouson), Arjen Markus (@arjenmarkus)

Fortran Standard Library (stdlib)

Strings

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), Milan Curcic (@milancurcic)

Containers

Fortran offers all the ingredients needed for building a library of abstract data types, such as linked lists, heaps or binary trees. There is quite a lot of material available already, but the aim of this project is to provide a standardised implementation that can be used "off the shelf". Some requirements: storage of arbitrary types of data, flexible API, so that all common uses are covered, open to further expansion.

Potential related issues:

• stdlib#27: Define a base user class to support ADTs, sorting
• stdlib#68: Linked list

Mentors: Arjen Markus (@arjenmarkus)

OS integration: filesystem

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:

• stdlib_os

Mentors: Milan Curcic (@milancurcic)

OS integration: subprocesses

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:

• Ideas for command module

Mentors: Milan Curcic (@milancurcic)

LFortran

FORD

Maintenance of the FORD project

• check and organize the issue tracker
• sort and review pull request
• ping pull request authors and merge patches

Mentors: Brad Richardson (@everythingfunctional)

Use fpm package manifest as project file

• extract meta data from fpm.toml file instead of FORD project file

Mentors: Sebastian Ehlert (@awvwgk)

Submitting your own idea

You are welcome to apply with your own idea if there is something not on this page that you are interested in and that you think would be a good addition to one of the repositories listed here.

As with the ideas listed here, please discuss your novel idea with us on our Discourse before making your application. This allows us to give feedback on the suitability of your idea as a Fortran-Lang GSoC project and identify potential mentors.