Follow dependent paths for USE statements.

[dnwillia-work]

Hi,

Can we please have an option to control where module (.mod) files are placed as well as included from?

In our project we need to put the module files in a different path outside of the source code area because we don't use the gfortran compiler normally. Though we like to use it for this extension :-).

I was able to force the generation to another location by adding this line to my settings.json

"fortran.linterExtraArgs": ["-J<path>"]

but then the Linter did not seem to figure out that I've forced it.

Dan

EDIT:

See comments below, there is a workaround, though, if you load a module the .mod files for dependencies are not generated on the fly so you end up with unresolved imports.

[pedro-ricardo]

Please see this comment, it's a tutorial of how to use the flags you want
Let me know if it helps

[dnwillia-work]

@pedro-ricardo OK, I had a read through the other link and I thought I tried adding the module path to the include path to see if that worked. It did not, otherwise I would not have posted this request. Let me try it again, I'll let you know.

[dnwillia-work]

@pedro-ricardo OK, I did it again and I can confirm that the combination of setting

"fortran.includePaths": ["<path>"],
"fortran.linterExtraArgs": ["-J<path>"]

is working, sort of.

The reason that I got tripped up testing this earlier is that if no module files are generated yet, then you must open the Fortran files in dependency order to get it working. So, for instance, lets say module a uses module b which uses a module c, located in files a.f, b.f and c.f, respectively, then I have to close everything and then open c.f, b.f and finally a.f. Then it hangs together perfectly.

Seems like you need some dependency scanning to generate the module files on the fly?

Edit: Since the include/linter paths functionality is working, I've updated the title of this issue, and the opening post, to reflect this last bit.

Dan

[pedro-ricardo]

Hello there @dnwillia-ansys, Thanks for your comments ...
You basically want an automatic makefile like the Eclipse IDE or the paid version of Visual Studio has.

It's a valid request and it makes a lot of sense, therefore I'll leave it marked as a feature-request.
But i'm sorry to say that i'm unable to do it. I didn't made the extension and the only thing I know how to handle are highlights, but please, feel free to make changes in the code and ask for a pull request.

[dnwillia-work]

@pedro-ricardo Thanks for the response! I don't think what I'm suggesting needs to be quite a full featured makefile/dependency checker. The extension could simply do two things:

• search for all the fortran modules in the project and generate all the .mod files to the -J location specified in linterExtraArgs (or the cwd if that is not specified, as it does now) So, in my example, a.mod, b.mod and c.mod are generated when the extension is initialized.
• regenerate the module file when you modify/save a.f, b.f or c.f. Probably it already does this.

[ScottBoyce]

@pedro-ricardo OK, I did it again and I can confirm that the combination of setting

"fortran.includePaths": ["<path>"],
"fortran.linterExtraArgs": ["-J<path>"]

is working, sort of.

The reason that I got tripped up testing this earlier is that if no module files are generated yet, then you must open the Fortran files in dependency order to get it working. So, for instance, lets say module a uses module b which uses a module c, located in files a.f, b.f and c.f, respectively, then I have to close everything and then open c.f, b.f and finally a.f. Then it hangs together perfectly.

Seems like you need some dependency scanning to generate the module files on the fly?

Edit: Since the include/linter paths functionality is working, I've updated the title of this issue, and the opening post, to reflect this last bit.

Dan

I agree with the other issues and this one that the mod files should be placed in a tmp folder.
I have a rather complicated makefile that places all the mod and o files into a single directory.
I ended up having to disable the extension because the .mod creation on the fly just meant my project had random mod files placed throughout my code repo.

Another option is to link it to a launch profile, which for mine just calls the makefile. This then would contain the dependency order and build all the mod files. Then the user can request when the linter needs to update with the makefile rather than having it automatically do it.

Specifically, have the extension linked to a tasks.json task name. Then have the user invoke when it should build the files. Then allow a custom location of the mod files (analogous to the -J option).