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!
 
Hi guys,

Publisher to run (and to be compiled) needs this file: /usr/local/bin/luahbtex but it must be called sdluatex; I solved this by making a symbolic link that solves me fatigue to learn how to send and apply a patch upstream.

The problem is that binary is shipped with the tex-luatex package that when is expanded it is almost 1G of storage:
Code:
pkg info tex-luatex
tex-luatex-20250308_1
Name           : tex-luatex
Version        : 20250308_1
Installed on   : Sun Nov 30 17:17:53 2025 EST
Origin         : print/tex-luatex
Architecture   : FreeBSD:15:amd64
Prefix         : /usr/local
Categories     : print
Licenses       : 
Maintainer     : tex@FreeBSD.org
WWW            : UNKNOWN
Comment        : Extended version of pdfTeX using Lua
Shared Libs required:
    libc++.so.1
    libc.so.7
    libcxxrt.so.1
    libgraphite2.so.3
    libharfbuzz.so.0
    libkpathsea.so.6
    libm.so.5
    libpng16.so.16
    libtexlua53.so.5
    libtexluajit.so.2
    libz.so.6
    libzzip.so.13
Annotations    :
    FreeBSD_version: 1500068
    build_timestamp: 2025-11-22T03:04:07+0000
    built_by       : poudriere-git-3.4.4-6-gd1913ec3
    port_checkout_unclean: no
    port_git_hash  : e3fa556c9a509b3bc0e615815d8368b663c95dc3
    ports_top_checkout_unclean: no
    ports_top_git_hash: 480b1085a2e0ba7fe13dc9313d413253a4999961
    repo_type      : binary
    repository     : FreeBSD-ports
Flat size      : 162MiB
Description    :
LuaTeX is an extended version of pdfTeX using Lua as an embedded
scripting language.  The LuaTeX projects main objective is to provide
an open and configurable variant of TeX while at the same time
offering downward compatibility.

I am pretty that to run the sp binary the full luatex suite is not required, therefore there is a method to download only that file from the official FreeBSD repos?

Thanks... 🙏
 
I think the problem is there are two use cases. An individual like you or I wants to build a port with the least effort necessary. In contrast, the FreeBSD package system MUST build everything. The package system isn't penalized like us for situations like the one you describe.
 
I am pretty that to run the sp binary the full luatex suite is not required, therefore there is a method to download only that file from the official FreeBSD repos?
Even though it's technically possible, I don't think anyone would commit to it.
The binary created by BUILD_DEPENDS=${NONEXISTENT}:print/tex-luatex:build may be installable as sdluatex, but it is not known whether it will be committed.
I don't think it would be acceptable.
 
Back
Top