Created attachment 163294 [details] Shell archive with port sources Neko/NekoML compilers, libraries and virtual machine. http://nekovm.org/ Optionally includes MySQL, GTK and Apache bindings/modules.
Created attachment 163295 [details] portlint -AC output
Created attachment 163296 [details] poudriere testport output
Created attachment 163297 [details] poudriere bulk -t output
On 32 bit architectures, this port adds "-mincoming-stack-boundary=2" to CFLAGS. This cmd line option is unknown to clang while presumably it is needed when compiling with gcc. Possible ways to resolve this: 1) Strip this option from cflags when clang is used. In this case you should verify that neko actually works on these architectures. 2) Enforce to compile with gcc on 32 bit architectures. Could you look into this?
Definitely, will let you know what can be done asap.
Created attachment 165539 [details] New version of the port I found a way to pull that flag out. Build is passing on i386, poudriere logs to follow.
Created attachment 165540 [details] poudriere testport output for amd64 architecture
Created attachment 165541 [details] poudriere bulk -t output for amd64 architecture
Created attachment 165542 [details] poudriere testport output for i386 architecture
Created attachment 165543 [details] poudriere bulk -t output for i386 architecture
Updated poudriere logs after changing the makefile, see attachments.
(In reply to Petr Penzin from comment #6) I had some time to look into it. There are some issues we have to work on before we can include this into the tree. This is what I have so far: - It is not clear where version "2.0f" comes from. The project homepage and the github repo mention only a 3 year old version 2.0. The GH_TAGNAME you used points to a minor commit that indicates no special significance. If you want to import a snapshot rather than a release into the three, that's fine, but in this case I'd suggest a numbering scheme compatible to the upstream project, e.g. "2.0.0.20150919". - By convention, we use the short GH_TAGNAME (7 digits), as in the GH commit log: https://github.com/HaxeFoundation/neko/commits/master - The OPTIONS dependencies need overhaul. Most of these are not BUILD_DEPENDS. If there is linking, it's a LIB_DEPENDS (e.g. gtk, pcre), if it uses an external binary at runtime, you certainly need RUN_DEPENDS, possible in addition to BUILD_DEPENDS. - Don't DEPEND on sqlite. There is USES= sqlite - If it depends on an external binary, don't have the port depend on a header file. - The neko tarball comes with its own versions of httpd.h and mysql.h which seem to be outdated copies from apache httpd and mysql. For instance, the build log indicates that during build it includes its own mysql.h file but links to ${LOCALBASE}/mysql/libmysqlclient_r.a without ensuring that those are actually compatible. That's a recipe for desaster. - Port does not honour system CFLAGS - LICENSE_*: Several files in this tarball are under GPL. If they are used and compiled in, is the resulting package really MIT? - LICENSE_FILE(s) should be added - The post-install-OPTION-off workarounds may even work in this case but it's not the proper way to take care of this. For instance, on a system where gtk is installed, the port should not pick up gtk during build at all if the OPTION is deselected. Normally there are configure switches or Makefile variables for this. If not, you might need to patch the build scripts accordingly. - You might need to pass LIB_PREFIX=${LOCALBASE} with MAKE_ARGS to allow build on systems with non-default LOCALBASE in make.conf. - Probably some more things that I have missed Sorry in case this looks like much at the moment. But some of the points are pretty easy and others are really upstream's fault. In any case we need to address them, because in its current state it's very likely that this port will break for many users.
Hi, Thank you for such a detailed feedback. Unfortunately I don't have answers to all of it, and I probably need to get upstream involved for some part. Here is what I can answer myself: - Contents of lib/include seems to be only used on Windows, though I will double-check. That includes both outdated headers. What is the best way to go about this? Patch to remove all those directories? - The license situation was a bit messy in that particular version, it has been cleaned up since, I will revisit that. - All the issues in port's Makefile (version, DEPENDS misuse, workarounds, etc) are my fault, will fix. Thanks again for the feedback!
(In reply to Petr Penzin from comment #13) If you don't want the build system to pick up certain files/dirs during build, some ports simply do something like this: post-extract: ${RM} -rf ${WRKSRC}/path/to/undesired/files others patch Makefiles, configure scripts etc. As long as it works and is understandable by others, it's up to you. Don"t worry too much about whose fault which bullet point was, really. It's not blaming or finger pointing. Some ports do require a little extra work compared to others. That's just how it is and always has been. Thanks for your patience and your efforts getting this one into proper shape!
Any news on the mentioned issues? Otherwise we may have to assume that there is no longer interest on getting this port into the tree.
Created attachment 172687 [details] Updated port
Created attachment 172688 [details] poudriere testport output for amd64 architecture
Created attachment 172689 [details] poudriere testport output for i386 architecture
Created attachment 172690 [details] portlint -AC output
Created attachment 172691 [details] poudriere bulk -t output for amd64 architecture
Created attachment 172692 [details] poudriere bulk -t output for i386 architecture
Created attachment 172693 [details] poudriere testport output for amd64 architecture
Created attachment 172694 [details] poudriere testport output for i386 architecture
I am uploading a new version of the port. It still uses a git hash for GH_TAG, but I can request a release tag if everything looks good. LICENSE variable is not updated yet, because poudriere does not support multiple licenses (more on license below). Improovements: - Builds are now done via CMake - mysql.h should not be an issue: it builds two different versions of mysql libraries. The one that includes mysql.h does not link against libmysql. - Project now has a comprehensive description on how it is licensed: https://github.com/HaxeFoundation/neko/blob/master/LICENSE Some of the potential issues: - Configuration options are disabled for now. In theory this build mechanism is better at it, but I think it still needs work. - The project is actually mulit-licensed. There are parts that are covered by LGPL, GPL, Apache and MIT licenses. Some advice would be greatly appreciated: Can configuration options be left out for now? How to deal with this licensing ragtag? I can provide what files fall under what license, but what are the mechanics of including something like that in ports collection?
Forgot to mention, there is a portlint warning about USES vs DEPENDS, but I pretty sure it is dues to sqlite being removed from "USES".
A commit references this bug: Author: riggs Date: Sat Nov 19 19:33:11 UTC 2016 New revision: 426533 URL: https://svnweb.freebsd.org/changeset/ports/426533 Log: Add new port: lang/neko, the neko programming language and VM PR: 204664 Submitted by: penzin.dev@gmail.com (maintainer) Changes: head/lang/Makefile head/lang/neko/ head/lang/neko/Makefile head/lang/neko/distinfo head/lang/neko/pkg-descr head/lang/neko/pkg-plist
Committed plus marked BROKEN on FreeBSD-9