Neko package

Neko package

[Andy Li]

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

Re: Neko package

[Marco Atzeri]

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

Re: Neko package

[Andy Li]

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 <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


Let me know if there is any remaining issue.

Best regards,
Andy

Re: Neko package

[Jon Turney]

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

[Andy Li]

> 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