GSoC 22: fpm-ize the Fortran Ecosystem || Blog Post by Arteev Raina || #3

Projects GSoC-2022
1

Good Day Everyone,

We are now into the third week of the community bonding period of the Google Summer of Code 2022 program.

This week majorly involved exploring the things about Fortran Package Manager in more depth and exploring its limitations, which makes the Fortran Packages difficult to make fpm compatible. I started out by looking at the things that a package manager helps us to solve. These involve:

  • Manage the dependencies.
  • Building the project.
  • Testing the project.
  • Creating a new project.
  • Searching the dependencies.

Expanding the second point, “Building the project”, though fpm is able to build the projects that don’t use preprocessors of any form, but when preprocessors are used in a Fortran Project, then current fpm is not able to build it. Also, most of the old and new Fortran Projects that I found on the web use preprocessor in some form which makes it necessary to add preprocessor support in Fortran Package Manager.

Then, I surveyed some Fortran packages on the web that use preprocessors. Some, packages like Fortran Template Library use CPP (C Pre Processors), stdlib uses Fypp, some other packages use prep and FMacro.

After the meeting last week, we decided that we will focus on CPP and come up with a manifest syntax for the preprocessor support and get it reviewed by the community and ask for suggestions or questions if any.

The tasks that I have planned for this week :

  • Reading more about C Pre Processors and Macros.
  • Analysing the syntax of the fpm.toml files of large Fortran Projects.
  • Come up with a manifest syntax for pre-processor support. I will try to keep the syntax pre-processor agnostic so that we can support other preprocessors in the future as well.

If you have any questions, do reach out to me at arteevraina@gmail.com or comment under this post.

Thanks,
Arteev Raina

7 Likes
2

Hey everyone,

I have come up with a tentative syntax for fpm.toml file for enabling preprocessor support in fpm. This is a tentative format and it can change with implementations and new suggestions from the community. So, I will request the community members to put in their suggestions.

Thanks & Regards,
Arteev Raina

[preprocessor]
# Whether use preprocessor ability or not.
preprocess = true
# This means C Pre Processor is used.
type="cpp"
# Specify the pre processor directives here.
directives=["define", "ifdef", "ifndef", "if", "undef"]

cc : @milancurcic @awvwgk

1 Like
3

Thanks, @arteevraina, nice start. A few comments and questions:

  1. Is it reasonable allow more than one preprocessor per project? I don’t know of any such project, but it’s imaginable (e.g. cpp + fypp). With that in mind, perhaps the preprocessor could be specified as a subtable, e.g.:
[preprocessor]
[preprocessor.cpp]
...

Then you could do:

[preprocessor]
[preprocessor.cpp]
...
[preprocessor.fypp]
...

If we decide that there’s no need for more than one preprocessor per package, then I like your syntax better.
2. I wonder if specifying directives is redundant if fpm can determine them from the preprocessor name. Rather, it seems more likely to me that specific macros would be set in the manifest.
3. I wonder if preprocess = true is redundant as well. The alternative is false, at which point we just omit the preprocess table from the manifest altogether. Or, is there a use case to have preprocess = false in the manifest?

1 Like
4

I would expect fpm will need to know which files should be preprocessed as well. I think just specifying file extension would be sufficient for most use cases, but perhaps an option for specifying specific files would be desirable also.

1 Like
5

Thank you @arteevraina for this proposition.

I have a few comments (also based on @milancurcic and @everythingfunctional 's comments):

  • As CPP is often supported by the compiler itself, it can happen that multiple preprocessors (e.g., fypp + CPP) are used in a single file.
  • I don’t understand why the directives used by the preprocessor must be mentioned. Furthermore, how could this be extended to preprocessors other than CPP (e.g., fypp)?
  • @everythingfunctional: could fpm preprocess all files? I guess it is what happens when providing a flag for CPP to a compiler with all files with the extension .f90. If it is too time-consuming for large projects, than a file extension would be appropriate (but what happens if two preprocessors are used in the same file?).
1 Like
6

IMO, any preprocessing of source files results in a two phase compilation process, as it becomes nearly impossible for fpm to know what the resultant file(s) contain or use in terms of modules, and thus doesn’t know any compilation dependencies until after preprocessing. It would I suppose be reasonable for any given file to be processed through multiple preprocessors prior to compilation, but that (I think) kind of necessitates specifying preprocessing on a per file basis. That seems quite complicated for something that is likely to be a very rare need. I’d say preprocessing based on file extension, with a single set of options for a given preprocessor across a project is about as complicated as fpm should really get. IMO if your project really does need that complicated of a build process, maybe fpm just isn’t the right build system.

2 Likes