fpm assumes .mod has the same name as the source file

[milancurcic]

If I have a source file datetime.f90 that contains a module called datetime_module, then gfortran (and all other compilers I believe) output datetime_module.mod. However, fpm expects datetime.mod and can't find it.

I believe the assumption about .mod filename comes from somewhere around here, however I don't have a solution right now.

I think the safe assumption is that the .mod file will have the module name, for fpm will need to scan the source file to get this info.

Further, a source file can have multiple modules defined, and for each the compiler will emit one .mod file.

[everythingfunctional]

That assumption actually comes from here.

The reasoning is that we want the file name to match the module name, and the module name to include the path components of the file name. This was a basic structure to help with organizing modules that @certik and I came up with.

There are ways to just inspect the source files and figure out the module names and dependencies more flexibly, but for our initial implementation we wanted to keep things as simple as possible and try and encourage a common organizational convention.

Obviously this is something that should be added to the README. @certik , do you think you'll have time to write up our standard conventions in the README any time soon?

[milancurcic]

Specifically for datetime-fortran, that's fine. I'm happy to rename the source file so it can build with fpm.

I also support encouraging the practice one module per source file, with file name matching the module.

However, I think this may be quite limiting if fpm is to build existing packages. I don't know, but it's possible that there are many that have multiple modules per source file.

This made me think now: why would there be an expectation for a specific .mod file to be present? AFAIK, the compiler cares only about the include path and that the modules are there. It knows how to find the file in the include directory. So, this requirement by fpm seems artificial to me. Could it be removed so that fpm only checks for .o files? I think it's safe to assume that if .o file is created, that the .mod files have been created as well.

[milancurcic]

However, I think this may be quite limiting if fpm is to build existing packages. I don't know, but it's possible that there are many that have multiple modules per source file.

Related to this, I think more problematic is that this requirement would prevent fpm from building correct and modern Fortran code.

[everythingfunctional]

It's more about rebuilds. If you change a module and rebuild, then if the .mod file changes, you need to rebuild everything that depends on it.

[certik]

Yes, the default layout restricts what can be done, and you want that. It's not meant as a replacement for cmake, which allows you to do anything, but you pay for it by maintaining a complex buildsystem. We want to rather create a convention, that would allow fpm to figure out everything by itself. For existing packages we either have to adapt them, or we need to tell fpm extra information where things are.

…

On Sun, Apr 26, 2020, at 10:22 PM, Brad Richardson wrote: It's more about rebuilds. If you change a module and rebuild, then if the .mod file changes, you need to rebuild everything that depends on it. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#57 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAFAWBXBCUBJJZTLO54K4LROUCBBANCNFSM4MRK6V2A>.

[milancurcic]

Okay, sounds good. We can revisit if it shows to be an issue, I don't think it is right now.

Yes, it'd be good to discuss and write out requirements for packages. I don't remember seeing this specific one anywhere.

[certik]

@milancurcic see #39.