From Newsgroup: muc.lists.freebsd.ports


Hi all,

until recently Datalevin, a database in the Clojure ecosystem,
used
databases/lmdb under the hood. Clojure runs on the JVM. Until
now it
was enough to tweak it to use the lmdb from ports.

The creator of Datalevin has recently forked lmdb using javacpp to
create the jni bindings to create a java library with the native
parts
called dtlnative.

I have spend the last week porting this to FreeBSD. Changes to
USearch, javacpp and dtlvnative to work on FreeBSD have been
accepted
upstream. Now I want to bring it into ports.

The new port databases/dtlvnative depends on
- USearch, new port math/USearch
- dlmdb, new port, fork of databases/lmdb
- javacpp, new port, java/javacpp

I have a running poudriere jail and the ports build.

The biggest questions I have are around testing and stubs.

Testing

I have build the Makefiles so tests run in do-build: and
BUILD_DEPENDS
contain, in one case, junit.

When I but these into TEST_DEPENDS and do-test: "poudriere
testport"
will not run them.

If I make do-install: depend on test poudriere complains about the
dependencies not being in BUILD_DEPENS, so I could leave the tests
in
do-build:. One of the reasons I want this in ports and not .so
files
in jars from maven is that I know the tests have run on FreeBSD.

Should I just leave tests in do-build: and BUILD_DEPENDS?

Stubs

JavaCPP requires OSGi and slf5j. I do not want to pull these in
for a
library/buildtool. To get it to work without these dependencies I
create stubs by ECHO_CMD to Java files.

What is the canonical way of going about this? An extra
stubs.jar?

Should I not do stubbing?

Should I put the stubs eg. in the files directory instead? If so
what
is the canonical way of using these from the Makefile?

I have no experience submitting ports so any extra advice is
welcome

Best regards

Markus
--
Markus Graf

Tel.: +49 172 840 26 08
Email: markus.graf@markusgraf.net



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

On Tue, Feb 24, 2026 at 3:51rC>PM Markus Graf <markus.graf@markusgraf.net> wrote:

I have spend the last week porting this to FreeBSD. Changes to
USearch, javacpp and dtlvnative to work on FreeBSD have been
accepted
upstream. Now I want to bring it into ports.

It sounds like you did an impressive work.

Testing

I have build the Makefiles so tests run in do-build: and
BUILD_DEPENDS
contain, in one case, junit.

When I but these into TEST_DEPENDS and do-test: "poudriere
testport"
will not run them.

That's right, poudriere testport does not do that (yet). But you can make Ports framework run tests as part of the build by defining WITH_TESTING=yes or WITH_TESTING_PORTS=your/port1 your/port2
in make.conf. In Poudriere context this config is located in /usr/local/etc/poudriere.d

If I make do-install: depend on test poudriere complains about the dependencies not being in BUILD_DEPENS, so I could leave the tests
in
do-build:. One of the reasons I want this in ports and not .so
files
in jars from maven is that I know the tests have run on FreeBSD.

Should I just leave tests in do-build: and BUILD_DEPENDS?

Put tests under the do-test target and its dependencies under TEST_DEPENDS.
Do not force users to always run tests during the build - currently this is an optional feature and is guarded behind WITH_TESTING knob.

Stubs

JavaCPP requires OSGi and slf5j. I do not want to pull these in
for a
library/buildtool. To get it to work without these dependencies I
create stubs by ECHO_CMD to Java files.

What is the canonical way of going about this? An extra
stubs.jar?

I'm not a Java expert, so not sure what's being talked about here.
But there is a BINARY_ALIAS knob that can be used to create
stub executables, you might find it useful.

Should I not do stubbing?

Should I put the stubs eg. in the files directory instead? If so
what
is the canonical way of using these from the Makefile?

What's the problem in properly wiring in those dependencies?
Are they heavyweight or not ported yet?

I have no experience submitting ports so any extra advice is
welcome

I suspect your patch would be lengthy, so I'd recommend you to
put your ports onto our Phabricator [1] or make a pull request
on GitHub [2]. Get me (@arrowd) on the hook and I will provide
a review.
[1] https://reviews.freebsd.org/
[2] https://github.com/freebsd/freebsd-ports
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

Gleb Popov <arrowd@freebsd.org> writes:

On Tue, Feb 24, 2026 at 3:51rC>PM Markus Graf
<markus.graf@markusgraf.net> wrote:

It sounds like you did an impressive work.

Thank you!

Testing

That's right, poudriere testport does not do that (yet). But you
can make Ports
framework run tests as part of the build by defining
WITH_TESTING=yes or
WITH_TESTING_PORTS=your/port1 your/port2
in make.conf. In Poudriere context this config is located in /usr/local/etc/poudriere.d

Put tests under the do-test target and its dependencies under
TEST_DEPENDS.
Do not force users to always run tests during the build -
currently this is an
optional feature and is guarded behind WITH_TESTING knob.

OK, thank you!

Stubs

I'm not a Java expert, so not sure what's being talked about
here.
But there is a BINARY_ALIAS knob that can be used to create
stub executables, you might find it useful.

I will look into that.

What's the problem in properly wiring in those dependencies?
Are they heavyweight or not ported yet?

One, slf4j, is ported, OSGi is not ported.
I do not think a library should force a choice of logging
framework on you. That should be the applications choice.
I do not want to needlessly replicate the location of jar files
since it will be hard to debug dependencies. The infamous
classpath.
I see these main valid reasons to put jar files into FreeBSD
ports:
1. they contain or are tied to native code.
2. having the ports infrastructure run the tests so we know when
something breaks.
3. they are a standalone applications, maybe even startable via
service start.
4. they need to be patched to run on FreeBSD or profit from
customization.
The main reason to make a port of JavaCPP instead of just using
the upstream jar was to have the tests. Also to have an official
FreeBSD capable jar before upstream cut a new release two days
ago.

I suspect your patch would be lengthy, so I'd recommend you to
put your ports onto our Phabricator [1] or make a pull request
on GitHub [2]. Get me (@arrowd) on the hook and I will provide
a review.

[1] https://reviews.freebsd.org/
[2] https://github.com/freebsd/freebsd-ports

Is one PR on github ok or should I submit one per port?
Once I am clear about the FreeBSD ports I will try to get one
other PR into dtlnative upstream before I send PR to you.
Thank you!
--
Markus Graf
Tel.: +49 172 840 26 08
Email: markus.graf@markusgraf.net
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

On Tue, Feb 24, 2026 at 5:40rC>PM Markus Graf <markus.graf@markusgraf.net> wrote:

Is one PR on github ok or should I submit one per port?

One PR is certainly fine, you can just put each port into a separate commit.
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21b-Linux NewsLink 1.2