Use project-local .curry as output directory if workspace contains multiple projects
#56
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
I.e. if the workspace contains multiple Curry projects, e.g. CPM packages, the language server will place icurry files for each project in its own <workspace>/<project dir>/.curry/language-server rather than <workspace>/.curry/language-server. Strangely, however, there still seem to be some files written to the workspace's folder, presumably those from the standard library etc. which don't have an associated dirPath.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Consider the following project layout
Currently, the language server will use
<workspace>/.curryas an output directory in any case sincedefaultOutDirpoints to./.curryand the language server's working directory is the workspace:curry-language-server/src/Curry/LanguageServer/Index/Store.hs
Line 261 in 668edfc
Given that the user will compile projects anyway from their respective subdirectories, it would make sense for the language server to use the local
.currydirectories as well, which is what this PR does. This additionally prevents clashes if the user has a module under the same name in multiple packages and unexpected cross-visibility between packages in the same workspace once compiled.Some more testing is needed, however, especially to make sure that dependencies use the correct out dir too etc.