我正在尝试清理fortran make进程以进行分发。目前，制作了两个库，然后编译可执行文件链接到库并包括模块文件。我从之前的答案（Distribute compiled fortran library with module files）中看到，你无法摆脱模块文件，并且它们对于每台机器和编译器都可以是不同的。这非常烦人。
但是，我的库中的代码完全由模块组成。好像我根本不需要图书馆部分;我可以只包括这些模块。我已经尝试了这个，它可以编译并运行在小例子上。
这总是有效吗（当我所有的都是库中的模块时）？这是最佳做法吗？我是否应该考虑重写我的库而不是使用模块，这样我就可以避免所有这些编译器依赖，只分发lib * .a文件？是this document使用子模块指的是什么（没有人支持static lib with many modules）
答案 0 :(得分：4)
这实际上取决于您库中的功能。它只有几个声明吗？然后.mod文件就足够了，但为什么不在这么简单的情况下分发源呢？
您的所有公共程序是否都足够简单，以便它们不需要显式接口而且它们不在模块之外？那么您不需要任何.mod个文件。
您是否有一个简单的公共模块或包含公共API的包含文件，其余的是私有的？然后，您可以分发API模块的源或包含文件。我建议只在这个模块中放置接口块和其他声明。
注意一个重要问题。你可以逃避（使用接口锁或类似的东西）避免使用非可移植的.mod文件，但如果程序使用了一些更高级的参数传递，那么它们的ABI通常不能在不同的编译器之间移植，甚至不能在某些编译器版本之间移植。在调用你的库时，你可以编译它并发生神秘的崩溃。
子模块可以改变这一切，但实际上我不认为它们会解决编译器之间的可移植性。您的库的用户仍然需要您拥有的相同编译器。确实，连接封闭源软件会更容易，但在编译器之间不能更容易移植。
答案 1 :(得分：0)
您可以从库lib * .a或目标文件链接。两者都至少是平台相关的，因此比源代码更难分发。库文件可能具有更少文件的优势。在任何一种情况下，从lib * a或目标文件链接，您都可以将代码作为要调用的过程库呈现给用户。如果您不想分发源代码，那么您必须为您支持的许多平台进行编译。模块是现代Fortran的一个主要优点，可以自动检查过程实际和伪参数。与例如C头文件相比，它们具有自动化的优点，但是产生依赖于编译器的中间文件的缺点。如果您正在向其他程序员提供程序，那么不向他们提供此接口检查似乎是个坏主意。如果要隐藏源代码，则可以编写描述过程的接口块，并仅分发此源以进行编译。