Added a few useful os calls to VM

[genotrance]

Consolidated wrappers by making them a bit generic rather than adding more for each new module/param/return combo.

Added the following procs since they are useful at compile time:-

• getCurrentDir()
• setCurrentDir()
• putEnv()

Added test cases for all os and ospath VM ops.

[Araq]

These are dangerous.

# yay, produces a binary that only runs on my machine
const myresource = getCurrentDir() / "file.txt"
discard readFile(myresource)

[genotrance]

Agreed, but they are are useful in the right context as well.

Is it a question of documenting the procs accurately to avoid such scenarios or do we want to prevent adding them to the VM altogether?

[Araq]

Maybe these should be called staticGetCurrentDir but again, what are you trying to solve? getCurrentDir is not a concept a Nim build should rely on.

[genotrance]

I'm working on a nimdeps module which can be used to embed files into the executable at compile time and then extract it at runtime (if not already present). It allows shipping a single file with all dependencies embedded.

It works fine if the module file is in the same directory as the application that uses it but fails if it's a nimble module since staticRead() is relative to the module file and not current directory. We already spoke about that on chat recently.

There's no way for nimdeps to figure out the path to any file that's relative to the build directory since it isn't known at compile time today. Further, using absolute paths makes the module useless as a general purpose nimble library that can be leveraged by any user.

This is one example of needing this functionality in the VM. I'm thinking there's other good reasons to need to know the current directory during compile time.

[Araq]

There's no way for nimdeps to figure out the path to any file that's relative to the build directory since it isn't known at compile time today. Further, using absolute paths makes the module useless as a general purpose nimble library that can be leveraged by any user.

The current diretory is not the build directory. What we need is pathRelativeToInvoker or something like that.

[genotrance]

Is there any other place in the compiler where the working directory gets changed during compile time?

[data-man]

@genotrance
Maybe, implement what you need as a compiler plugin?
See locals.nim, e.g.
PContext.module.filename can be helpful, probably.

[genotrance]

Based on discussion, removed getCurrentDir() and setCurrentDir() and instead added getProjectPath() to macros which returns options.gProjectPath.

Retained putEnv() as is since it is still useful.

[genotrance]

Added to changelog under "Compiler changes"