[Feature request] a FreeBSD port

[ppenzin]

As discussed, I would like to add Neko to a FreeBSD's Ports Collection. I can find some traces of a Neko port and it also seems like it was taken down.

I apologize in advance if that is too straightforward to someone, I want to explain what I am trying to do to those not very familiar with the process. Also, feedback is welcome and appreciated!

Information on how Ports Collection works can be found in Porter's Handbook. There is a straight-forward walkthrough of a simple port at the beginning.

A binary install package is created automatically for every port (not right away though).

Port files

To do get a port we need four files:

Makefile
distinfo
pkg-descr
pkg-plist

pkg-plist and distinfo can be (and should be) autogenerated, more on that below.

pkg-descr:

The Neko Programming Language

Neko is a high-level dynamically typed programming language which can
also be used as an embedded scripting language. It has been designed to
provide a common runtime for several different languages.

WWW: http://nekovm.org/

Makefile (with my comments):

# $FreeBSD$

# Port identification information. Version is made up, since the port is not
# pointing to any release yet.

PORTNAME=       neko
PORTVERSION=    2.0p
CATEGORIES=     lang

# This can be me, though can put any other email address instead

MAINTAINER=     petr@somewhere.com

# A short version of what this port is about

COMMENT=        Neko programming languages and virtual machine

# Self explanatory: license and GC library

LICENSE=        MIT
LIB_DEPENDS=    libgc-threaded.so:${PORTSDIR}/devel/boehm-gc-threaded

# Disable make -j

MAKE_JOBS_UNSAFE=yes

# Where to get the code from. This points to my own github repo, since I
# needed to make some changes to the code. Will need to use
# official Neko repository. Also, GH_TAGNAME can be a release name.

USE_GITHUB=     yes
GH_ACCOUNT=     ppenzin
# GH_PROJECT is the same as port name
GH_TAGNAME=     6138f0808895e54cf998cb644d1f4b255dbf83f4

# Build and install setting. Pointing INSTALL_PREFIX to where FreeBSD expects,
# setting a target that would produce stripped binaries.

USES=           gmake
MAKE_ARGS=      os=freebsd INSTALL_PREFIX=${STAGEDIR}${PREFIX}
# Use default build and install targets ("all" and "install" respectively)

# Run a smoke test after installing

post-install:
        cd ${WRKSRC} && ${MAKE_CMD} ${MAKE_ARGS} test

.include <bsd.port.mk>

I would really appreciate any feedback on this. Also, if you are curious or want to test my work read below for instructions.

Port generation and testing

For the curious, to generate the rest of the port on a FreeBSD machine first generate checksum (as root, connected to the internet):

# make makesum

This will download a tarball into distfile directory and create distinfo with a checksum. Then get a list of files to add to pkg-plist (root not required):

$ make makeplist
...
/you/have/to/check/what/makeplist/gives/you
bin/neko
bin/nekoc
bin/nekoml
bin/nekoml.std
bin/nekotools
include/neko.h
include/neko_mod.h
include/neko_vm.h
lib/libneko.so
lib/neko/mysql5.ndll
lib/neko/regexp.ndll
lib/neko/sqlite.ndll
lib/neko/std.ndll
lib/neko/zlib.ndll

Copy the list of paths at the end of the output to pkg-plist file in the same directory. After that you can proceed to test it as described in Porter's Handbook.

[rudrabhoj]

Hello. WIFEXITED is not in stdlib.h in FreeBSD, it is in sys/wait.h instead. So libs/std/process.c need to add this:

#ifdef NEKO_BSD
#   include <sys/wait.h>
#endif

[ppenzin]

That's true, I've seen that being an issue with ocamllibs. I can send in a fix if you don't mind.

But nonetheless, does anybody have any feedback on my request?

[ncannasse]

Sorry I can't comment on it, I'm not familiar enough with ports

[rudrabhoj]

A FreeBSD port would really be awesome. neko is working fine in my FreeBSD 10.2 box. I am not familiar with the working of git, so please send them a pull request with <sys/wait.h> path :P btw, is the port working on your box?

[ppenzin]

Updated the makefile at the beginning of the thread.

@ncannasse would you mind if I submit it myself, pointing to HaxeFoundation/neko repository as it is (not to my own fork)? I'll take care of the blame mail if something goes wrong as well.

@vyal Pull request is in. The port works for on my machine, but I haven't done any poudriere runs on it yet (that helps to convince port commiters). You can try playing with it locally too.

[ncannasse]

@ppenzin no problem for me

[ppenzin]

I ran into libraries problem: need to define what neko libs would be installed. It seem that Debian neko package comes with regexp, sqlite and mysql.

What libraries do you want to see in the port? The easiest (but least practical) way is to include everything by default and may be let user exclude some of the libraries if they are building the port (binary package would come with everything). I can separate some of the libraries into additional ports (for example apache modules and GTK bindings can have their own ports).

[ncannasse]

all of the libs here are usually installed as part of neko distrib https://github.com/HaxeFoundation/neko/tree/master/libs (apart "ui") we have two versions of mysql : "mysql.ndll" which statically links libmysqlclient_r.a and "mysql5.ndll" which is a full protocol rewrite with no dependency to libmysqlclient, but only handles TCP connection as for mod_neko/mod_tora, if they compile from source using local apache version it's good. either they require to build several versions for different apache versions

[ppenzin]

Thanks for the explanation!

I got them all to build (unfortunately required minor code change, pull request is coming) and enabled them in the port by default. If a user will build it they will be able to opt out of building some/all libraries, but when installing as a binary package everything will be in.

Another problem is I ran into is that FreeBSD want all installed binaries to be stripped. And even though most of them are, libneko.so and the libraries are not. Should I add a strip step to the install target or add a separate install-strip target? If not I can probably handle that in port files.

[ppenzin]

Thanks, with this I am almost done. I can build and install. I am sending one more pull request for strip changes, let me know if you want that.

[ncannasse]

Can we close now ? :)

[ppenzin]

Was just waiting for #69 to come to some resolution :)

If you want me to just take current HEAD, I'll try that.

[ppenzin]

One of the questions I got from a ports committer that I could not answer was about headers in libs/include. Contents of libs/include is only used on Windows (that's what LICENSE file in it says), right?

[andyli]

Yes, those are only used on Windows.

[ppenzin]

Thanks!

On Mon, Jan 18, 2016 at 11:34 PM, Andy Li notifications@github.com wrote:

Yes, those are only used on Windows.

— Reply to this email directly or view it on GitHub https://github.com/HaxeFoundation/neko/issues/84#issuecomment-172764400.

[andyli]

@ppenzin Any update on this? ;)

[ppenzin]

Sorry, I got the most of the port working, but then stuck on licensing, FreeBSD wants to have a license stated for the project, but there are quite a few here: https://github.com/HaxeFoundation/neko/blob/master/LICENSE

They have an API for declaring different licenses for different parts of the project, but I am not sure how that would work yet.

I don't know if we should keep the issue open since the progress is very slow.

[andyli]

For the license, you can specify multiple licenses as suggested. You may also split neko into several packages if needed, e.g. neko, neko-mysql, neko-zip, etc, and each of them may have different licenses according to our LICENSE file.

Let's keep this issue open since there may be people who are interested in using neko in FreeBSD as well.

[ppenzin]

Thanks, "split into multiple packages" approach looks interesting, I didn't think about that.

[ppenzin]

FreeBSD committers puzzle me - after grilling me for months, they just went and accepted the code, even without waiting for me to update the version :)

[ppenzin]

We are in: https://reviews.freebsd.org/rP426533

[andyli]

lol Thanks for your work! Will you make a port of Haxe too? ;)

[ppenzin]

I can try

[rudrabhoj]

Haxe already compiles on FreeBSD. Problem is getting hxcpp and lime work. I have successfully used haxe with JS target there.

On Nov 23, 2016 10:43 AM, "Petr Penzin" notifications@github.com wrote:

I can try

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/HaxeFoundation/neko/issues/84#issuecomment-262436081, or mute the thread https://github.com/notifications/unsubscribe-auth/AGkSuLkNvtB0mpNepTnuh3O82Uh3M3W3ks5rA8uRgaJpZM4Fhtbf .

[ppenzin]

I did try to build haxe on FreeBSD, but ran into trouble with OCaml, that I don't know how to resolve. Anyway, that should be probably a separate task, I can open issue on Haxe repo.

Will there be a release with CMake changes (made since last release) soon? Those will help with enabling build options in the port.

[andyli]

I want to have a new release too. The only thing I wish being resolved in the next release is #126, but I honestly lack the knowledge to work on it...

[ppenzin]

I was going to look at it, but never got to the build to work, sorry.

[andyli]

I've fixed #126 and released Neko 2.2.0. Please update the FreeBSD port ;)

[saper]

I have submitted the necessary changes to @ppenzin:

[ snip ]

Well, it doesn't seem to be that simple. I don't know why cmake is used in such a relatively complex way...

I had to patch cmake files like this:

--- libs/sqlite/CMakeLists.txt.orig     2018-01-31 22:50:39 UTC
+++ libs/sqlite/CMakeLists.txt
@@ -29,7 +29,7 @@ else()
        add_library(sqlite.ndll MODULE sqlite.c)
        pkg_check_modules(SQLITE3 REQUIRED sqlite3)
        target_include_directories(sqlite.ndll PRIVATE ${SQLITE3_INCLUDEDIR} ${SQLITE3_INCLUDE_DIRS})
-       target_link_libraries(sqlite.ndll libneko ${SQLITE3_LIBRARIES})
+       target_link_libraries(sqlite.ndll libneko ${SQLITE3_LDFLAGS} ${SQLITE3_LIBRARIES})
 endif()

... this way we get rid of an ugly (and incorrect) FreeBSD workaround:

--- CMakeLists.txt.orig 2017-12-19 06:38:08 UTC
+++ CMakeLists.txt
@@ -9,11 +9,6 @@ project(Neko C)
 set(CMAKE_OSX_ARCHITECTURES x86_64)
 set(CMAKE_MODULE_PATH ${CMAKE_SOURCE_DIR}/cmake ${CMAKE_MODULE_PATH})

-if (${CMAKE_SYSTEM_NAME} STREQUAL "FreeBSD")
-  # FreeBSD puts all thirdparty libraries in /usr/local
-  link_directories(/usr/local/lib)
-endif()
-
 # put output in "bin"

 set(OUTPUT_DIR ${CMAKE_BINARY_DIR}/bin)

I just wonder why find_package is not enough...?