I guess that's progress ... some #PowerShell on #FreeBSD at least starting up. Creating a #port out of this will be a lot of work 😞 had to patch quite some code, e.g. completely disable the "login shell" functionality, the implementations only work on either #Linux or #MacOS....

And the whole build system fails completely if not built from within a #git working copy ... WTF? This will be another challenge for porting.

Ah, this messy version is probably a result of the mess in the upstream repo, a tag v7.4.1 exists, but refers to a commit that is gone.

Oh what did I expect ... 😂

This will be though.

Well, I can certainly build #PowerShell for #FreeBSD now. I might be able to just "fake" a #git working copy for its stupid build system. This still doesn't fully solve the version issue, it insists on appending the git hash -> TODO.

The "login shell" feature can be added, an exercise left for later, the code will look pretty similar to the existing MacOS-X implementation. Maybe upstream would even accept it 😎

For a #port, it should probably be "published" as "#ReadyToRun" (I hope this has no negative impact), otherwise lang/dotnet would become a hard run dependency ... This works now as well, but requires changes in lang/dotnet ... requires some platform-specific #NuGet packages that don't exist on MS servers for FreeBSD. They are created during build of dotnet itself, but not installed anywhere by default ... I'll suggest an "on by default" port option to bundle these with lang/dotnet.

[…]

The biggest issue will probably be to find some at least somewhat sane way to download the required #NuGet packages during #port fetch phase, so they can be used "offline" during build later. Of course if ever possible with correct checksumming in distinfo.

This is always the same annoying crap with all these languages and frameworks inventing their own package management. Sucks.

For #NuGet, I tought the commandline client could maybe help with the task. Well if anyone can tell me how to even build that thing ... I guess I'll give up and look for other ideas. Should be possible to somehow automate the process to get the correct uris for package downloads? And then maybe patch the build files of #PowerShell to exclusively use a local directory as the "package source" ... we will see.

And now, "staging" and packaging for #FreeBSD works as well 😎

But this is just the "base" #Powershell with no bundled modules. Next step, find out how to build and bundle some "essential" Modules, e.g. #PSResourceGet and/or #PowerShellGet (for Install-Module), and #PSReadLine (for sane commandline editing and stuff) ... any more that absolutely NEED to be bundled? 🤔

Next "milestone", bundling #PowerShell modules with the #FreeBSD package (using the nupkg files available from powershellgallery) works! 🥳

One little thing missing, some of these are auto-imported, others are not ... why? 🤔

Edit: They are auto-imported as soon as you invoke a commandlet ... nice! 😎

Ok, time to commit to my local branch of #FreeBSD ports. Can't go to main yet because building still requires some patches to lang/dotnet ...

In case you want to test #PowerShell on #FreeBSD *NOW* ... here's a patch for #ports:
https://people.freebsd.org/~zirias/patches/0001-shells-powershell-Add-new-port.patch

It currently requires at least these patches applied before:
https://reviews.freebsd.org/D44560
https://reviews.freebsd.org/D44561

Note they will probably change, the maintainer of lang/dotnet is looking for better options to solve these issues.

Well, I wanted to test #FreeBSD #PowerShell for my usecase (which I *guess* I have, still not entirely sure), but ... I thought now that the port works, let's first rebase #ports (on main).

BAAAD idea. Not only did some change force my #poudriere to rebuild more or less *everything*, I also had fallout to fix from new #LibreSSL incompatibilities and some strange build error with #llvm-17.

Right now STILL waiting for the build of #chromium to finish.

Ok, testing PowerShell: tomorrow. 🙄

Testing #PowerShell on #FreeBSD can finally start!

Already found the first issue ... it seems #PSReadline needs terminfo-db from ports installed to work correctly 🙄 -- port will be updated!

@zirias

I wonder how much more this has to happen before some momentum gains behind an effort to switch #FreeBSD to #terminfo. (I vaguely remember that there's an open issue that has been languishing for years.)

@mpts @zirias

No. #FreeBSD provides only #termcap as standard right now. #terminfo is only available as a port.

It's possibly the only mainstream operating system where this is still the case. NetBSD and OpenBSD both provide terminfo. I haven't checked Illumos.

https://github.com/freebsd/freebsd-src/tree/main/share/termcap

@david_chisnall @JdeBP @mpts AoT didn't work for some reason, currently it's using "--sc -p:PublishReadyToRun=true"

https://github.com/Zirias/zfbsd-ports/blob/local/shells/powershell/Makefile

@zirias @JdeBP @mpts If I understand correctly, Ready To Run embeds the JIT in the binary, which probably means you need several of the same dependencies as the dotnet port. You almost certainly need libunwind. Are you building with Poudriere? It should tell you about missing library dependencies, but it may not if they're dynamically opened.

EDIT: I was misreading the port, looks like you're already depending on the right libraries.

@david_chisnall @JdeBP @mpts Sure, libunwind and libinotify, they're already in LIB_DEPENDS. Of course this is all tested in poudriere. My biggest concern about the port now is how to handle the nuget stuff. But I can't push it anyways yet as it needs changes to the dotnet port first, reviews ongoing 😉

See also:
https://lists.freebsd.org/archives/freebsd-ports/2024-April/005839.html