Как повторно использовать модули Fortran без копирования исходного кода или создания библиотек

У меня проблемы с пониманием того, можно ли / как использовать код в нескольких проектах Fortran без создания библиотек или дублирования исходного кода.

Я использую Eclipse / Photran с компилятором Intel (ifort) в системе Linux, но я считаю, что у меня более серьезная концептуальная проблема с модулями, чем с конкретными инструментами.

Вот простой пример: в ~ / workspace / cow у меня есть исходный каталог (src), содержащий cow.f90 (ПРОГРАММА) и два модуля m_graze и m_moo в m_graze.f90 и m_moo.f90 соответственно. Этот проект правильно компилируется и связывается для создания исполняемой «коровы». Исполняемый файл и модули (m_graze.mod и m_moo.mod) хранятся в ~ / workspace / cow / Debug, а объектные файлы - в ~ / workspace / cow / Debug / src.

Позже я создаю ~ / working / Sheep и использую src / Sheep.f90 в качестве программы и src / m_baa.f90 в качестве модуля m_baa. Я хочу «использовать m_graze, only: ruminate» в Sheng.f90, чтобы получить доступ к подпрограмме ruminate (). Я мог бы просто скопировать m_graze.f90, но это может привести к рассинхронизации кода и не принимать во внимание какие-либо зависимости, которые может иметь m_graze. По этим причинам я бы предпочел оставить m_graze в проекте cow и скомпилировать и связать с ним файл Sheets.f90.

Если я попытаюсь скомпилировать проект овцы, я получу ошибку вроде:

error #7002: Error in opening the compiled module file.  Check INCLUDE paths.   [M_GRAZE]

В разделе «Свойства: ссылки на проекты для овец» я могу выбрать проект «Корова». В разделе «Свойства: Fortran Build: Settings: Intel Compiler: Preprocessor» я могу добавить ~ / workspace / cow / Debug (расположение файлов модулей) в список включаемых каталогов, чтобы компилятор теперь находил модули cow и компилировал Sheep.f90. Однако компоновщик умирает примерно так:

Building target: sheep
Invoking: Intel(R) Fortran Linker
ifort -L/home/me/workspace/cow/Debug -o "sheep"  ./src/sheep.o
./src/sheep.o: In function `sheep':
/home/me/workspace/sheep/src/sheep.f90:11: undefined reference to `m_graze_mp_ruminate_'

Обычно это решается путем добавления библиотек и путей к библиотекам в настройки компоновщика, за исключением того, что нет соответствующих библиотек для ссылки (это Fortran, а не C.)

Проект cow был отлично способен скомпилировать и связать cow.f90, m_graze.f90 и m_moo.f90 в исполняемый файл. Тем не менее, хотя проект овец может скомпилировать Sheep.f90 и m_baa.f90 и может найти модуль m_graze.mod, похоже, он не может найти символы для m_graze, хотя вся необходимая информация присутствует в системе для этого. .

Казалось бы, легко настроить компоновщик ifort, чтобы найти недостающие части и собрать их вместе, но я понятия не имею, какие волшебные слова нужно ввести, где в пользовательском интерфейсе Photran, чтобы это произошло.

Я признаю полное отсутствие интереса и компетентности в C и процессе сборки C, и я бы предпочел избежать отвлечения на создание библиотек (.a или .so), если только это не единственный способ заставить эту работу работать.

В конечном счете, я ищу решение этой проблемы на чистом языке Fortran, чтобы я мог сохранить единственную копию исходного кода и мне не приходилось вручную поддерживать кучу пользовательских файлов Makefile.

Так можно ли это сделать?

Приносим извинения, если это уже было где-то задокументировано; Google показывает мне только простые примеры сборки, как создавать модули и как связываться с существующими библиотеками. Кажется, нет (м) примеров повторного использования кода с модулями, которые не включают дублирование исходного кода.

Редактировать

Как отметили респонденты, файлы .mod необходимы, но недостаточны; либо объектный код (в форме m_graze.o), либо static или общие библиотеки должны быть указаны на этапе связывания. Файлы .mod описывают интерфейс объектного кода / библиотеки, но оба они необходимы для создания окончательного исполняемого файла.

Для такой упрощенной игрушечной задачи, как эта, этого достаточно, чтобы ответить на поставленный вопрос.

В более крупном проекте с более сложными зависимостями (в моем случае 80 + KLOC из F90, связанного с MKL-версией LAPACK95), IDE или инструментальной цепочке может не хватать достаточных средств автоматического или пользовательского интерфейса для совместного использования единого канонического набора исходных файлов. жизнеспособная стратегия. Выбор, по-видимому, стоит между риском рассинхронизации дублирующихся исходных файлов, отказом от многих преимуществ IDE (т. Е. Отказом от ручного создания файлов make / CMake / SCons) или, по всей вероятности, обоими способами. Хотя система контроля версий и хорошая организация кода могут помочь, ясно, что совместное использование единого канонического набора исходных файлов между проектами далеко не просто, учитывая текущее состояние Eclipse.