Mirror of forum.nim-lang.org

492 :: What are the long-term plans for dynamic libraries?

• PV (orginal) [2014-07-10T23:08:32+02:00] view original

  Right now they are supported on C-like level (separate building, exported API needs manual annotation, no metadata).

  Is something more advanced considered? I imagine an ability to state "modules A, B and C belong to my.exe executable, modules D and E into lib1.dll, module F into lib2.dll" and then the compiler would scan all the sources to discover what gets used across DLL boundaries and automatically generate exported functions.

---

• Araq (orginal) [2014-07-11T08:41:26+02:00] view original

  There are no plans for this. However, we do have a build tool (nake) and nimrod pretty is supposed to become a general "rewrite nimrod code" tool and with these you can build the feature yourself. In any case the focus should be on making the compiler more usable as a library.

---

• PV (orginal) [2014-07-11T12:01:12+02:00] view original

  I found the nake and quite like the idea. Will it eventually make into nimrod distribution? I found no documentation for nimrod pretty.

  the focus should be on making the compiler more usable as a library

  What capabilities will this enable? (I know about idetools.) Are there plans to support code hot-swapping, Erlang style?

---

• Araq (orginal) [2014-07-11T14:48:41+02:00] view original

  Are there plans to support code hot-swapping, Erlang style?

  Implementing hot swapping at the DLL boundary level seems to be very very simple. Let's see if I can push somebody to implement it.

---

• Demos (orginal) [2014-07-11T16:52:54+02:00] view original

  I just want to jump in and say that in general c# style "assemblies" are not a very good idea even if we did support them. I could see blobs with definitions and the pre-parsed code in binary form useful as a library distribution unit, but I don't really like the idea of embedding the output type into modules more than it is. I /do/ like the idea of making the compiler fully controllable from the source files, so that build tools and this kind of thing could just be written in nimrod.

---

• PV (orginal) [2014-07-11T19:41:14+02:00] view original

  Demos: metadata (if that's what C# assemblies mean - I have no knowledge of those) may help to catch invalid DLL use (e.g. incompatible compiler settings). This is quite a common problem for teams. I do not like dynamic libraries per se (they make everything even more complicated) but a large Nimrod project would surely need them to compile in finite time.

  For me the ideal in this direction would be full embedding of sources, building & debugging & analytical tools inside an application (where demanded), so it could be changed/debugged/recompiled on demand/verified/inspected/reasoned about anywhere and anytime.

---