The nimrod compiler is a portable binary, but without the standard library of modules it is pretty much useless (see long rant at http://gradha.github.io/articles/2013/08/users-prefer-static-linking.html). I would like to add an option to koch so that after compiling the binary it appends all the modules form the standard library to the compiler for it to work portably on any system.
The question would be how to implement this. I have previously used resource appending tools (aka dat) in the Allegro 4 library, which also provides compression. Maybe it would be worth looking at the fifth version to see if they have improved this support or reduced it to some minimal library which avoids including all the graphic stuff.
I fear however that this change would also require the compiler to actually know about the appended resources, and make a reasonable decision if the current path includes the same module: should the compiler prefer the embedded version or the new one available?
I fear however that this change would also require the compiler to actually know about the appended resources
Yeah but that's a very nice feature for nimrod i too, so I don't mind adding it.
a reasonable decision if the current path includes the same module: should the compiler prefer the embedded version or the new one available?
The new one available IMO.
Maybe at times you would like the embedded stdlib to override the one available on the local hard disk. You could have the global default nimrod installation for all users, then a user has a specific version of his own and for some reason prefers it to the system one. Could be useful for containment of unit testing. Well, looking at the compiler switches it seems that would not be a problem, since there's --excludePath.
I'll start looking on how to implement the data appending.
I have packaged a basic test at https://github.com/gradha/nimrod-ouroboros. Please see the installation and usage section and try the binary. Does it work under windows, linux? Big endian architectures?
I'll continue improving this module until it can be used properly with say Aporia, then it can be integrated with the nimrod compiler.
Well, http://github.com/gradha/Nimrod/tree/ouroboros3 is not yet ready for production, but I've managed to get working a macosx static nimrod compiler. Anybody brave to give it a whirl? First get the compiler from [removed link, see below], then unzip and try to compile the provided hallo.nim (or if you feel brave, anything else really):
$ unzip testing_ouroboros.zip
$ cd testing_ouroboros
$ ./ouroboros c -r hallo.nim
Ugh, I was playing with UPX and took a compressed binary instead of an uncompressed one. UPX hides everything behind a loader so that's why the dynamic libraries were empty. Here's a non compressed binary along with a linux one I made in a virtual machine:
http://dl.dropbox.com/u/145894/t/ouroboros_linux.zip
The portable binary of the compiler is generating weird nimcache paths when I put it in a different path. By default on my machine the compiler lives at ~/project/nimrod/root/bin/nimrod, and when I compile other projects at ~/project/nimrod/* everything works fine. However when I move the ouroboros compiler to ~/bin the compiler still works, but instead of generating a relative nimcache directory, it generates a relative path like project/nimrod/the_hyperlink_vs_nimrod/nimcache, basically prepending from ~ to the current path again.
The culprit lies in the compiler/options.nim file, proc getGeneratedPath. The change which started to produce this behaviour doesn't comment why it was done, and presumably it was done for other reasons, reverting the change would likely break something else. Maybe shortenDir is doing the bad thing? Without documentation it is hard to know what the proc is even meant to do.
So what to do?
Another example which currently happens. With the following configuration:
$ which nimrod
/Users/gradha/project/nimrod/root/bin/nimrod
$ pwd
/Users/gradha/project/nimrod/root/examples