Thinking about moving to FPM for some of my codes. I currently have my source files in multiple subdirectories under a parent src directory. The information in the following link:
implies I must rename my modules to match the package name, path etc. If that is still true that is a show-stopper for me wrt using FPM. Is this still true or is this page out of date (and if its out of date please fix this ASAP). Also, it took me a while to find this page. Things like this should be a one click access from the main FPM page.
Specifically, the page states the following
For modules defined in subdirectories, there’s an additional requirement:
module name must contain the path components of the directory that its
source file is in. In our case, src/math_constants/fundamental.f90 defines the
math_constants_fundamental module. Likewise, src/math_constants
/derived.f90 defines the math_constants_derived module.
This rule applies generally to any number of nested directories and modules.
For example, src/a/b/c/d.f90 must define a module called a_b_c_d.
Takeaways from this example are that:
You can place your module source files in any levels of subdirectories
inside src.
The module name must include the path components and the source file
name–for example, src/a/b/c/d.f90 must define a module called a_b_c_d.
@rwmsu, the information you’re pointing to from the automated documentation (FORD) is certainly out to date, I suggest you use the main documentation site which can be found at
The only caveat is whether you’re planning to upload a package to the centralized registry, in which case, naming conformity to the package name (or to another available custom prefix) is requested.
I find the info on the naming.html link to be confusing. The starting note says the naming requirements only apply to packages targeted for the fpm registry. O.K. great but you then go to great length to define a “preferred” naming convention. I would suggest you rename the page to reflect that it only applies to the case where you wish to upload to the registry. Even then, I find any requirement that imposes any kind of naming convention for any reason a big impediment to me ever using FPM. Thanks anyway.
We discussed that and eventually tried to design this in a way that:
user is still free to use the names they want
registry needs to enforce some naming (think how many packages could have some module utilities: if two dependencies have this module, compilation would fail) in the user’s and the ecosystem’s interest
you can think of this as “good practice”: package managers tend to have plenty of packages, each doing their own relatively narrow thing, so, it makes sense to enforce module naming. Easier to do it when starting a new package; converting huge monolithic repos to consistent naming clearly requires work, but as said on line #1 of that page, it is not necessary as long as a package is not designed to be uploaded to the open-source registry.
When using subfolders for app or example or test, fpm properly detects all the executables and they can be displayed with
fpm run ---list
fpm run --example --list
fpm test --list
This works properly for apps, examples or tests written in Fortran. However, it seems that it does not work when the sources are in C.
Do I need to explicitly declare, in the fpm.toml file, all the examples, apps and tests written in C or there is a workaround?