Following up my quest of packaging Haxe. After creating a Cygwin
package for mbed TLS, here is another one: Neko, which is a VM kind of
comparable to Lua. Neko is maintained by the Haxe Foundation. More
info of Neko can be found at http://nekovm.org/.
> Following up my quest of packaging Haxe. After creating a Cygwin
> package for mbed TLS, here is another one: Neko, which is a VM kind of
> comparable to Lua. Neko is maintained by the Haxe Foundation. More
> info of Neko can be found at http://nekovm.org/.
> The cygport file I created can be found at:
> https://github.com/andyli/neko-cygwin >
> Please review and let me know if it is up to standard or not.
> Best regards,
there is a double
>>> neko requires: cygwin libneko2 libneko2 neko-std-ndlls
As libneko2 dependency is already catch by cyport you don't need to
explicitly declare it.
> there is a double
>>>> neko requires: cygwin libneko2 libneko2 neko-std-ndlls
> As libneko2 dependency is already catch by cyport you don't need to
> explicitly declare it.
I've removed the explicit libneko2 from neko_REQUIRES.
> We usually prefer to have at least a minimal manual, like debian
> https://packages.debian.org/sid/amd64/neko/filelist >
> specially as the programs are not following standard expectation
> $ ./neko --help
> Uncaught exception - load.c(181) : Module not found : --help
> From this point of view, it seems a lack of Neko in general.
Yes, it is quite funny that the Neko VM doesn't even support --help...
Anyway, I've just created some manpages that are based on the Debian
ones, which are somewhat outdated.
I will update the manpages in the Debian package next time I update
it. (I'm the maintainer of the Debian package)
> Any reason to not build debuginfo and skipping strip ?
It is mainly because "nekoc", "nekoml", and "nekotools" are built in a
special way, using "nekotools boot <file.n>".
The way it works is to copy "neko.exe" and appends it with the
"file.n" Neko bytecode.
If the output file is stripped, the appended bytecode will be removed.
I myself consider it a bad way of producing executables, and for the
next version of Neko, those exe will be built "properly", such that
they can be stripped.
For more info, see https://github.com/HaxeFoundation/neko/issues/130
> Looks ok to me. I added neko to your package list.
Thanks! I will upload the package soon!
>> # cygport cannot auto detect these, since the ndll files are not
>> # named with .dll.
> If these really are just .dll by another name, you might want to explore
> patching cygport to teach it that (it already has to deal with some other
> non-standard extensions for DLLS)