I think, one thing that is crucial for using nimrod for linux development is support for dynamically linkable modules and shared runtime. E.g. standard runtime library, nimrod-implemented gui toolkit and so on. It's crucial for developing a big software suite like desktop environment and/or it is just inefficient to statically link a lot of gui code into a number of small tools developed in nimrod and used as a suite.
So, is there a transparent way to link runtime and several modules statically or dynamically like in traditional C/C++ code? What problems to solve here to support it?
BTW, exposing each module as a sole DLL is inefficient as well, probably a package-like concept is needed to group several modules into a dll...
What problems to solve here to support it?
Probably the same problems Free Pascal has to face: dll versioning and system module supported data types.
The first one is just about mixing different version of the dll with other dlls and/or programs requiring it. Not a big problem IMO, but still a problem, especially when doing partial update.
The second one is more difficult, you have to ensure in the WHOLE program there's only one and only one instance of the system module, otherwise the gc and managers would be duplicated and easily cause crash or memory leak.
Nimrod RTL can already be deployed as dll, so I guess this is one step ahead.
Nimrod already has a means to group modules into a DLL; nimrtl.dll does it via a custom rtl pragma. Its implementation is not tricky:
when defined(createNimRtl):
{.pragma: rtl, exportc: "nimrtl_$1", dynlib.}
elif defined(useNimRtl):
when hostOS == "windows":
const nimrtl* = "nimrtl.dll"
elif hostOS == "macosx":
const nimrtl* = "nimrtl.dylib"
else:
const nimrtl* = "libnimrtl.so"
{.pragma: rtl, importc: "nimrtl_$1", dynlib: nimrtl.}
else:
# nop pragma:
{.pragma: rtl.}
proc exampleProc*() {.rtl.} =
# depending on the compiler switch, this is either a header
# that is imported or the implementation for the DLL
echo "implementation here"