feat: link LFortran with -I #44
Conversation
server/src/lfortran-accessors.ts
Outdated
| const flags = ["--show-document-symbols", "--continue-compilation"]; | ||
| // run `echo "$(find . -type d | sed 's/^/-I/')"` and pass it as an argument to lfortran using spawnSync | ||
| // Execute the command within a shell | ||
| const find_output = spawnSync("echo $(find $(pwd) -type d | sed 's/^/-I/')", { shell: true }); |
There was a problem hiding this comment.
I think this has several problems:
- it will insert insane long command line arguments for large repos
- it will have collision problems for projects that have unrelated projects with modules with the same name
- it depends on
findandsed, which is not available on all platforms (like Windows)
server/src/lfortran-accessors.ts
Outdated
|
|
||
| // generate .mod files for the module | ||
| const module_flags = ["-c", "--continue-compilation"]; | ||
| const run_module = await this.runCompiler(settings, module_flags, text, "[]"); |
There was a problem hiding this comment.
Does this mean lfortran now runs twice every time for each key stroke?
|
This shows where the problem is and a quick prototype fix. Thanks for figuring it out. However the right fix is to let the use specify the path via an option. Maybe we can add an option to automatically include all subdirectories, but it seems hackish. Regarding regenerating of However. As discussed, we should save the proper compiler option into the |
server/src/lfortran-accessors.ts
Outdated
| const module_flags = ["-c", "--continue-compilation"]; | ||
| const run_module = await this.runCompiler(settings, module_flags, text, "[]"); | ||
|
|
||
| this.logger.info( |
There was a problem hiding this comment.
This should be logged as a debug message instead of an info message. It will also be logged, already, if you set your log level to trace in the extension's settings.
Aah yes, makes sense. |
Do you mean option in extension settings? or in |
Pranavchiku
force-pushed
the
snap-build
branch
from
578dd03 to
09ea957
Compare
|
I just cleaned the PR and kept it in a state which if we come up with no solution can be merged and get SNAP working on macos / linux. Now looking at incorrect location information of module files. |
|
Perfect! Much better approach. |
Ah, this is what the feature flags are for. I prefer this approach, too. I'll go ahead and submit a PR against your other feature branch to make it use an array of strings instead of a single, space-separated string. Space-separated strings for multiple command arguments are risky for situations such as when a user wants to include a path with a non-standard character in its name, like a space character. |
|
I think we can close this PR now, it's been implemented in other PRs. |
With this SNAP works, the trouble is location information of variables in different modules. This PR now links
-Ievery directory so that it finds mod files and link.