I’m trying to help package version 1.14.0 of the HDF5 library via MSYS2 and MINGW.
There’s a question of where to place .mod files when packaging.
Previously, they were placed in bin/static/Release and bin/shared/Release. It’s been suggested that they be moved to the include folder. I do not have much experience with this, so I would appreciate your insight.
Just my two cents:
To solve this puzzle I suggest you look at the solution fpm uses.
As @Arjen says, .mod files are specific to both a compiler vendor and a compiler version. So the short answer is that you don’t package them.
So how would linking to a library compiled with a set of flags X to a code compiled with a set of flags Y work then?
AFAIK when packaging people tend to cover multiple compiler vendors, compiler versions and other external libraries like MPI.
To be sure that it works you’d have to make a bind(c) interface to the code. The static archive could be packaged with a source file declaring the interface in order to make it easy and safe to use.
This isn’t unique to Fortran, but applies to e.g. C++ as well. One reason for this is that different compilers have different name mangling schemes, but the memory layout for types can also be different. When using MSVC (possibly others as well) you can’t pass a std::string between code compiled in release mode to code compiled in debug mode because the memory layout will be different.
The approach I use is to set up a shared module directory, and put all modules that are shared by programs in several directories into that directory. When compiled, these create one or more .mod files in that directory and also a .o file in that directory. I usually move the .o file into a library (.a file), which can then be referenced by the programs that use those shared modules. Of course, if the programs that share the modules are all in the same directory, then you usually don’t need to do anything, the compiler and linker find both the .mod files and the .o files automatically.
This is a little more complicated than libraries that do not have .mod files. If the library has only .o files, then you can move them into libraries and move them to other directories pretty freely. If the library has .mod files, then these files must be available at compile time for all the programs that reference them, whereas the .o files only need to be available at load time.
At one time back in the 1990s I remember a compiler that allowed you to place the .mod files also into a library, which was searched at compile time. I’m unsure if that is still possible. I did not use that feature because it was not portable to all the compilers I was using at that time.