Module-definition or DEF files (*.def) are text files describing attributes of a dynamic-link library (DLL) (the shared library concept for the Windows operating system). They are a Windows concept not tied to CMake.
Similar to how Fortran has public and private attributes for module variables and procedures, you can think of module-definition files or the __declspec(dllexport) attribute as way to enforce storage-class attributes on items (functions, data) which are to be part of a shared library.
There are several reasons why fine-grained control of symbol visibility is needed
- enforcing the public/private nature of an API
- security concerns and protecting intelectual property (e.g. exposing names of internal subroutines could give away information)
- shared library performance; i.e. the linker can discard symbols which it is sure are not used, resulting in a smaller binary object and faster startup times
The book Professional CMake: A Practical Guide - 16th Edition contains a sub-chapter on symbol visibility among other topics related to distributing libraries.
Currently fpm doesn’t support shared libraries. There is a tracking issue: Producing shared libraries · Issue #681 · fortran-lang/fpm · GitHub. The question has been asked on Discourse before: [fpm] can fpm be used to build a dynamic link library? - #6 by hkvzjal
I suppose it could export a DEF file, given a list of symbols. But you arrive at the same problem, either you introduce an an attribute !fpm$ dllexport, meaning fpm needs a parser and also has to know about the compiler name mangling, or you put this information into the fpm.toml manifest, re-inventing the DEF file syntax in the fpm manifest schema.
The Windows documentation has an article discussing the pros and cons of the different export methods: Determine Which Exporting Method to Use | Microsoft Learn