Re: Neko package
> 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) > Good idea! I will look into it. Best regards, Andy
Re: Neko package
On 30/04/2017 18:51, Andy Li wrote: Let me know if there is any remaining issue. Looks ok to me. I added neko to your package list. # 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)
Re: Neko package
Hi Marco, Thanks for the review! > 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 > > /usr/share/man/man1/neko.1.gz > /usr/share/man/man1/nekoc.1.gz > /usr/share/man/man1/nekoml.1.gz > /usr/share/man/man1/nekotools.1.gz > > 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 ". 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 Let me know if there is any remaining issue. Best regards, Andy
Re: Neko package
On 30/04/2017 15:30, Andy Li wrote: Hi, 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, Andy Hi Andy, 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. We usually prefer to have at least a minimal manual, like debian https://packages.debian.org/sid/amd64/neko/filelist /usr/share/man/man1/neko.1.gz /usr/share/man/man1/nekoc.1.gz /usr/share/man/man1/nekoml.1.gz /usr/share/man/man1/nekotools.1.gz 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. Except that, it is GTG for me Any reason to not build debuginfo and skipping strip ? Regards Marco
