update janet-lsp to be a "binscript" so it doesn't need to be updated whenever janet is updated

[dave_freedave.net]

Summary

The author of janet-lsp explained that it is better to use the "binscript" than the static executable for janet-lsp.

This means that if your end user is using a different version of Janet than the one you used to package the LSP, they could get different results from running a .janet script using their installed binary of Janet vs what the LSP will report as diagnostic errors. I would think this is more of an issue when the user is using a NEWER version of Janet, since that copy of Janet will have symbols in the standard library that the LSP version of Janet will not recognize (and therefore give errors about).

As you can see, its not that janet-lsp as a static executable stops working. Its that it stops agreeing with the installed janet.

I'd rather avoid such confusion.

The janet-lsp.jimage file is installed in LOCAL_BASE/lib/janet where other janet libs go. Because the image has its dependencies this will not cause problems if other ports want to install different versions of the dependencies. Think of it as fully linked "janet bytecode".

I can't seem to tease jpm(1) into using the right paths so I took the file it generates and made a janet-lsp.in for the two line "binscript". And now of course, janet-lsp does have a runtime dependency on janet.

Test Plan

Still testing. I don't expect issues but I need to redo the poudriere testbuild etc. I'll update when testing complete.

The usual: make test, kick the tires on stable/14, stable/15, and current, poudriere testbuild

[adamw]

It looks good to me, Dave, so let me know when your testing is done and you’re ready to get it committed.

[dave_freedave.net]

I had some bad grammer in janet-lsp.in comments. This just fixed that.

Also I have now tested it on stable/14, stable/15 and current.
First I I did a pkg uninstall janet-lsp followed by pkg install janet-lsp. This left my janet at 1.39.1 and I verified it worked with that.
Then I did a pkg upgrade and verified it worked with the janet it was built against.

So the binscript is much more (hopefully fully) independent of the janet version installed.

[adamw]

devel/janet-lsp/Makefile

55

Just making sure you're aware: INSTALL_* use install(1) semantics, so the destination filename is optional unless you're changing it.

There are many reasons to specify the destination filename, so this is just an FYI.

Also: I really like that you aren't using @ to silence things (ex. @${MKDIR} ${STAGEDIR}...). Also purely optional, but it feels important to me to show end users (and to document in logs) what is happening.

[dave_freedave.net]

devel/janet-lsp/Makefile

55

I was not aware the destination filename is optional. If you think its worth it I can change and update the review. Let me know.

I'm very much opposed to hiding what make does. I want all the whole command to see what went wrong on any failure. Glad we see eye to eye on that :)

[adamw]

I've committed this, but I noticed something in the build logs:

=======================<phase: package        >============================
===== env: DEVELOPER_MODE=yes PACKAGES=/tmp/pkgs PKGREPOSITORY=/tmp/pkgs PKGLATESTREPOSITORY=/tmp/pkgs/Latest 'PKG_NOTES=port_checkout_unclean' 'PKG_NOTE_port_checkout_unclean=no' STRICT_DEPENDS=yes USER=root UID=0 GID=0
===>  Building packages for janet-lsp-0.0.11_1
===>   Building janet-lsp-0.0.11_1
pkg-static: DEVELOPER_MODE: Notice: arch "FreeBSD:15:amd64" -- no architecture specific files found:
**** could this package use a wildcard architecture?
===========================================================================
=>> Recording filesystem state for preinst... done
=======================<phase: install        >============================
===== env: DEVELOPER_MODE=yes STRICT_DEPENDS=yes USER=root UID=0 GID=0
===>  Installing for janet-lsp-0.0.11_1
===>  Checking if janet-lsp is already installed
===>   Registering installation for janet-lsp-0.0.11_1
pkg-static: DEVELOPER_MODE: Notice: arch "FreeBSD:15:amd64" -- no architecture specific files found:
**** could this package use a wildcard architecture?

That warning message means that nothing appeared to be compiled past IR or bytecode. By default, pkg and poudriere assume that different versions of a port must be built for each architecture and each FreeBSD version.

If a port defines NO_ARCH= yes then only one version will be produced (per FreeBSD version, IIRC) and the stored ABI annotation will switch from FreeBSD:15:amd64 to something like FreeBSD:15:*. This is preferable whenever possible. I've never played with it, but I think there's a separate variable for when a pkg can be reused across different FreeBSD versions (I could be 100% wrong about that).

I didn't just add it in because I'm not actually sure what a jimage or jdn file contains. But, if it in fact is truly architecture-agnostic, then we can add NO_ARCH to the Makefile.

[dave_freedave.net]

The jimage file is truly architecture independent. Not just amd64 vs arm64. But it works for FreeBSD, Linux, Windows, basically anything that has a janet interpreter.
The jdn file is the janet equivalent of edn which is the clojure equivalent of JSON. It is just recording what is inside the jimage.

I think we can safely go NO_ARCH= yes. Is that urgent or can it wait for (ideally both of):

• review D54185 so I can pull out my build dependency on janet (since jpm will have it)
• review D54116 so I can switch to inotify standardization

[adamw]

In D54260#1240189, @dave_freedave.net wrote:

I think we can safely go NO_ARCH= yes. Is that urgent or can it wait for (ideally both of):

It absolutely can wait.