First time (trying) to create a port I need guidance

Charlie_

Thank you for all these tips, however I am step before, I am still trying to figure out if I must stay into /usr/ports/speedata or if this is irrelevant to create a port… 😓
 
mrd Your goal is to create a small set of files that may include patch files. The upstream code is not included in the port.

Running make will fetch the upstream code from an authoritative source like github, apply your patch files, and then build the port.

I don't know what speedata does. If it falls under sysutils then the port might belong under /usr/ports/sysutils/speedata.

If you can, locate an existing port based on golang and steal from that for you layout.
 
  • Thanks
Reactions: mrd
mrd, do you mean this one, right?

If so, and if rake and ruby is only needed for sphelper build system, you'd better splitting sphelper to be independent port (something like devel/sphelper, nonexistent at least for now) and BUILD_DEPEND to it.

It will reduce direct dependencies of main port only for builds and maybe make things simpler. You can share distfiles and distinfo between both.

An example is paired x11/nvidia-driver and x11/nvidia-kmod.

As everything shared are in x11/nvidia-driver side, looking into near the top of x11/nvidia-kmod/Makefile could help understanding how it can be done.
 
Thinking about your recommendations...

sphelper could go under /usr/ports/tools and definitely publisher must lie into /usr/ports/print.
 
Thinking about your recommendations...

sphelper could go under /usr/ports/tools and definitely publisher must lie into /usr/ports/print.
No for /usr/ports/tools/shepler. Ports are created as /usr/ports/<category>/<portname> where <category> is pre-defined.
You can see them just under /usr/ports. Beware! Any directories starting from capitals are parts of ports infrastructure and not allowed to be used for other use-cases.

There's no "physical" category tools. And creating new physical category is considered as infrastructual change that need approval of portmgr.
And build tools not specific to maintaining ports / pkgs are in devel category like devel/cmake. So sphelper would be better to be devel/sphelper.

On the other hand, I personally have no objection for print/publisher as it is not exists currently.
 
  • Thanks
Reactions: mrd
It looks like sphelper is not really relevant to build publisher I am checking this with Patrick on the other side.
 
I extracted the information from building Publisher with the aid of an LLM, but I don't really trust it so I am going to do some verification before to post it...
 
This first script worked, although further testings are needed:

Code:
#!/bin/sh
# build_sp_lib.sh – builds luaglue.so and libsplib.so for FreeBSD
# Adjust the variables below to match your project layout.

# Exit on error, treat unset variables as an error, and propagate failures in pipelines.
set -eu
# The `pipefail` option is not available in /bin/sh on FreeBSD, but the
# combination of `set -e` and careful command usage gives similar safety.

# ----------------------------------------------------------------------
# Configuration – change these paths as needed
# ----------------------------------------------------------------------
SRCDIR="/home/sp/publisher-5.3.16/src"   # root of the repository
BUILDDIR="/home/sp/publisher-5.3.16/lib" # where the shared objects will be placed
BUILD_PRO="${BUILD_PRO:-false}"           # set to "true" to build the pro version

# ----------------------------------------------------------------------
# Prepare build directory
# ----------------------------------------------------------------------
DYLIB_BUILD="${BUILDDIR}/dylib"
mkdir -p "${DYLIB_BUILD}"

# ----------------------------------------------------------------------
# 1️⃣  Build the C glue library (luaglue.so)
# ----------------------------------------------------------------------
echo "=== Building luaglue.so (FreeBSD) ==="
cd "${SRCDIR}/c"

cc -shared -fPIC \
   -o "${DYLIB_BUILD}/luaglue.so" \
   luaglue.c \
   -I /usr/local/include/lua53/

# ----------------------------------------------------------------------
# 2️⃣  Build the Go SPLib library (libsplib.so)
# ----------------------------------------------------------------------
echo "=== Building libsplib.so (FreeBSD) ==="
cd "${SRCDIR}/go/splib"

export CGO_ENABLED=1
export CGO_CFLAGS="-I /usr/local/include/lua53"
# FreeBSD does not need special LDFLAGS for this build
export CGO_LDFLAGS=""

LIB_EXT=".so"                     # FreeBSD shared‑object extension
OUTPUT="${DYLIB_BUILD}/libsplib${LIB_EXT}"

# POSIX‑compatible test – use single brackets instead of Bash’s [[ ]]
if [ "${BUILD_PRO}" = "true" ]; then
    go build -tags pro -buildmode=c-shared -o "${OUTPUT}" speedatapublisher/splib
else
    go build -buildmode=c-shared -o "${OUTPUT}" speedatapublisher/splib
fi

echo "=== Build complete ==="
echo "luaglue.so  → ${DYLIB_BUILD}/luaglue.so"
echo "libsplib.so → ${OUTPUT}"

Code:
./build_sp_lib.sh
=== Building luaglue.so (FreeBSD) ===
=== Building libsplib.so (FreeBSD) ===
=== Build complete ===
luaglue.so  → /home/sp/publisher-5.3.16/lib/dylib/luaglue.so
libsplib.so → /home/sp/publisher-5.3.16/lib/dylib/libsplib.so

Code:
ls lib/dylib/
libsplib.h      libsplib.so     luaglue.so
 
Looks good. You also need to build the sp binary, and pass a lookup-kind to the compilation process. See https://github.com/speedata/publish...f191a95ea328e42012fc3/src/go/sp/sp/sp.go#L182 and https://github.com/speedata/publisher/blob/develop/src/go/sphelper/distcustom/distcustom.go - I don't know if you need a different directory structure. If yes, we could add this to the sp distribution. (ping me on GitHub if you need this)

Thank you!!! 🙏

I was actually about to ask for help on Github, but now I realized I was working on the wrong file to create the sp binary!

I will make new tests and keep everybody posted!
 
Back
Top