Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Strange interaction with a linter #769

Closed
rouson opened this issue Oct 5, 2022 · 3 comments
Closed

Strange interaction with a linter #769

rouson opened this issue Oct 5, 2022 · 3 comments
Labels
bug Something isn't working

Comments

@rouson
Copy link
Contributor

rouson commented Oct 5, 2022

Description

Is fpm copying the entire source tree (src) into the build tree? If so, would it be acceptable to change that behavior so that only program source files get copied and not everything else? I just spent several hours attempting to make changes to code that perplexingly caused inconsistencies with previous versions of the code. I felt like I was in an episode of the Twilight Zone in which multiple points along a timeline existed simultaneously. Eventually I concluded that the problem was because I switched editors. I was at one point using VS Code's Modern Fortran extension, which includes a linter that generated various *.mod and *.smod files in my source tree. I later switched to editing in vim, but my old .mod and .smod files were getting swept up in the build process and I was seeing errors caused when newly renamed variables in my submodule weren't being recognized because their declarations were in the parent module and an outdated .mod file was being used in the build process.

If I have correctly diagnosed this issue, then I'm hoping I don't need to generate a simple reproducer and the fix is for fpm to never copy .mod or .smod or similar files from the source tree into the build tree. If having .mod and .smod files in the source tree is problematic, then it will be difficult or impossible to use a linter.

Expected Behaviour

I would not expect old .mod and .smod files to be used in the build process.

Version of fpm

0.6.0

Platform and Architecture

macOS

Additional Information

No response

@rouson rouson added the bug Something isn't working label Oct 5, 2022
@awvwgk
Copy link
Member

awvwgk commented Oct 5, 2022

Is fpm copying the entire source tree (src) into the build tree?

The latest stable and the current head are never doing this. This will be introduced with #729 for fypp files in the future. Also, fpm will never explicitly place mod files in the source tree, only few compilers, like LFortran, are currently ignoring the module output directory provided by fpm and can produce mod files in the current working directory.

Eventually I concluded that the problem was because I switched editors. I was at one point using VS Code's Modern Fortran extension, which includes a linter that generated various *.mod and *.smod files in my source tree.

Maybe you hit the same issue as Minh @minhqdao in #758? The linter seems to output mod files by default in the current working directory which can lead to this kind of strange behavior. cc @gnikit.

@rouson
Copy link
Contributor Author

rouson commented Oct 5, 2022

@awvwgk thanks! Yes, I believe the suggestions in #758 will solve my problem. I'll close this issue.

@rouson rouson closed this as completed Oct 5, 2022
@gnikit
Copy link
Member

gnikit commented Oct 5, 2022

I think your diagnosis @rouson is correct. Modern Fortran by default dumps .mod, .smod files into whererver the source file is located. This is was more of a limitation rather than a features of me not knowing where to dump these linter files. You can control the output dir by setting the option "fortran.linter.modOutput": "${workspaceFolder}/build/linter" in the settings.

PR fortran-lang/vscode-fortran-support#683 fixes this issue by default and writes the linter generated files into an obscure VS Code cache

Also, point 3.1 in this Discussion #768 proposes how to solve this problem on the fpm side

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants