Mirror of forum.nim-lang.org

1464 :: What about lib/wrappers?

• vega (orginal) [2015-07-21T12:34:44+02:00] view original

  Question about this issue: https://github.com/nim-lang/Nim/issues/2949. What are the plans for these wrappers in the future?

---

• Varriount (orginal) [2015-07-21T14:34:51+02:00] view original

  Well, if you look at the issue, you'll see that it was closed following a commit that removed the ambiguously licensed libraries. Most, if not all of them, should be available on Nimble.

---

• vega (orginal) [2015-07-22T06:31:53+02:00] view original

  Not all of them :-(

  
  > nimble install zlib
  zlib not found in local packages.json, check internet for updated packages? [y/N]
  Run

  
  >nimble install libzip
  libzip not found in local packages.json, check internet for updated packages? [y/N]
  Run

---

• vega (orginal) [2015-07-22T10:34:06+02:00] view original

  Recreated zlib. Compared to the old version:

  • fixed compilation on Windows (verified on gcc 4.9 and visual c 2003)
  • removed dll/so/dylib dependency

  Link: https://github.com/vegansk/nimzlib

---

• Demos (orginal) [2015-07-23T19:00:43+02:00] view original

  Can we /please/ not use {.header.} here, it does not actually remove the dynlib dependency and it adds things that the compiler does not know about. Also it means that generated C code will compile slower since nim has less specific information about dependencies.

---

• andrea (orginal) [2015-07-23T19:04:31+02:00] view original

  @Demos: can you explain? I have certainly used {.header.} before and I am not aware of any issues that it causes, nor of any alternatives to using it

---

• Demos (orginal) [2015-07-23T19:48:35+02:00] view original

  you can just use {.importc, dynlib:...} and the compiler will import the function without actually #including the header. Essentially when you use {.header.} the compiler can generate names that conflict with stuff in the header, most C libs are pretty good about prefixing their functions but the #include inserted is transitive. Also if the nim compiler knows about all the symbols in your module it will generate perfect forward declarations in C and this makes compiling your code faster.

  Also note that dnylib does not actually introduce a dependency on the dll/so any more than {.header.} does, you still need the library (either static or dynamic) with header and you can get static linkage using --dynlibOverride

---

• Araq (orginal) [2015-07-23T20:31:04+02:00] view original

  Not all of them

  Uh, sorry about that. I will add them to Nimble as soon as possible.

---