Store only the base name of a source file in the fsmod file

[dorchard]

Previously .fsmod files were storing the file filename, which makes them not very portable when using a tool at a different relative directory to the fsmod (this was the underlying issue behind camfort/camfort#190 in CamFort.

This simple fix stores only the files base name in the fsmod file which makes them more portable/referable from different directory contexts.

[mrd]

Ok, thoughts:

• genUniqNameToFilenameMap will only work on a list of parsed modfiles that occur in the same dir
• .fsmod files will have to accompany the source fortran files in the same dir, they can't be gathered into another dir (e.g. a build/ dir) without losing track of the original source file

plus side:

• may fix a related bug where it attempts to prepend the dirname to the already fully-specified (absolute/relative) path

[dorchard]

How problematic do you see the first couple of points being? (note this fixes this issue in CamFort: camfort/camfort#207)

[mrd]

How problematic do you see the first couple of points being? (note this fixes this issue in CamFort: camfort/camfort#207)

I had originally envisioned the .fsmod files as being something that could be collected separately as part of a build system, like .o files going into a build/ dir. I could relax that view personally, I don't know if there are any people out there using .fsmod files in this way (collecting them in a separate dir from the source) who might object to changes.

Largely, I think this pull request does make things cleaner, aside from that.

[mrd]

I'm not sure why there's a problem with ghc 9.0, the other ones seem to work though. Seems to be a linking problem with th-orphans - unrelated?

[mrd]

I'm not sure why there's a problem with ghc 9.0, the other ones seem to work though. Seems to be a linking problem with th-orphans - unrelated?

The problem fixed itself. Best kind of problems. 😄

[mrd]

One idea, going back to the fundamental conflict, is perhaps to store a SHA1 hash of the original Fortran file, rather than its path. At least then there is something that can be compared, given different Fortran files of the same name (or perhaps different revisions in time of the 'same file').

[dorchard]

Yes this is a great idea... perhaps we should do this!

[dorchard]

sorry need to review - will do next week. does it solve the the camfort issue camfort/camfort#207?

[mrd]

I'm making a new camfort branch fortran-src-0.17 since the API has changed for modfiles. You can see how it affects things there. camfort/camfort#227