Documentation fix, bump version

README.md

@@ -262,19 +262,25 @@ recommended to use an additional switch with `useFutharkFor<project name>`.
 A complete sample would look a bit something like this:
 
 ```nim
-const futharkFile = "futhark_generated/generated.nim"
 when defined(useFuthark) or defined(useFutharkForExample):
-  import futhark
+  import futhark, os
 
   importc:
-    outputPath futharkFile
+    outputPath currentSourcePath.parentDir / "generated.nim"
     path "<path to library>"
     "libfile.h"
 else:
-  include futharkFile
-
+  include "generated.nim"
 ```
 
+Keep in mind that when your package is installed the generated Futhark output
+would be placed in the folder of your package using this code. If the
+`/ "generated.nim"` part is left of then the file would be named
+`futhark_<hash>.nim` as described above, this means that your `include` could
+use the one specified in your package installation, while users doing
+`useFuthark` would generate one based on its hash (or reuse yours if the hash
+matches).
+
 # But why not use c2nim or nimterop?
 Both c2nim and nimterop have failed me in the past when wrapping headers. This
 boils down to how they are built. c2nim tries to read and understand C files

futhark.nimble

@@ -1,6 +1,6 @@
 # Package
 
-version       = "0.7.4" # Remember to update the version in futhark.nim as well
+version       = "0.8.0" # Remember to update the version in futhark.nim as well
 author        = "PMunch"
 description   = "A package which uses libclang to parse C headers into Nim files for easy interop"
 license       = "MIT"

src/futhark.nim

@@ -3,7 +3,7 @@ import macroutils except Lit
 
 const
   Stringable = {nnkStrLit..nnkTripleStrLit, nnkCommentStmt, nnkIdent, nnkSym}
-  VERSION = "0.7.4"
+  VERSION = "0.8.0"
   builtins = ["addr", "and", "as", "asm",
     "bind", "block", "break",
     "case", "cast", "concept", "const", "continue", "converter",