Other fvwm3

zirias@

Developer
I finally found the time to update x11-wm/fvwm3 to the latest release (1.0.4). It works fine for me and fixes at least one nasty bug that was present in 1.0.2. Also, building the new Go module FvwmPrompt now works flawlessly, so I added a port option to enable it (but left it disabled by default, although I'm unsure what the majority of users would expect here?)

I hope it will "land" soon, meanwhile you can find the patch in PR 258716.

PS: sorry for the delay, I normally try to keep "my" ports updated more timely… :oops: My excuse is personal life, I became father recently… :cool:
 
Well, I had some discussion on a (german) IRC channel related to *BSD about default options … and I now think it might be better to enable the new GO option by default?

There's always the people complaining about "bloat", and well, let's see:
Code:
$ ls -lh /usr/local/bin/fvwm3 /usr/local/bin/FvwmPrompt
-r-xr-xr-x  1 root  wheel   893K 25 Sep. 12:42 /usr/local/bin/fvwm3
-rwxr-xr-x  1 root  wheel   2,5M 25 Sep. 12:42 /usr/local/bin/FvwmPrompt

Yep, that new Fvwm module written in Go is a few times larger than the wm itself 😳 – plus it pulls in yet another build dependency (Go).

OTOH: FvwmPrompt is much better in terms of usability than the old FvwmCommand/FvwmConsole stuff. And 2.5MB on disk, that's ridiculous for current machines. It might "feel" wrong to go down a road of all static linking, but in practice, does it really hurt?

Of course, this is only really relevant for users of the package. If you build the port, there's the option, so it's your own decision whether you want Go or not.

Any discussion? Right now I feel like I'll update my patch to enable GO by default.
 
My excuse is personal life, I became father recently… :cool:
Ah congrats!

Get them trained up and they can help you maintain your ports ;)

By enabling GO by default, (just for that single module?) How many extra packages will that drag in? Go compiles native and has a fairly small runtime so it might not be *too* bad.

Is there any way it could be split into two packages? fvwm3 and fvwm3-prompt? Yes more annoying for the maintainer. But pulling in languages like this *is* more annoying. (That said, I do understand somewhat why the upstream made this choice).
 
By enabling GO by default, (just for that single module?) How many extra packages will that drag in? Go compiles native and has a fairly small runtime so it might not be *too* bad.
It pulls in Go as a build dependency (needless to say I guess), nothing else. And the binary is kind of large (see above) because all the Go dependencies are linked statically. But yep, I guess that's a fair price for giving users of the package the more comfortable FvwmPrompt. I'll update my patch :)

BTW, thanks a lot, I hope I can teach him "computer stuff" :cool:

Edit:
Is there any way it could be split into two packages? fvwm3 and fvwm3-prompt? Yes more annoying for the maintainer. But pulling in languages like this *is* more annoying.
This is certainly possible (flavours) and I'm totally unwilling to do that, sorry ;)
 
Ah OK, cool. Well all I can really say is that if it doesn't add more dependencies to the *package*, I will personally look forward to migrating :)

It is only really if it dragged in a new interpreter, runtime, another llvm-xxx and countless npm-like dependencies (for binding against X11, etc), then I might consider sticking with fvwm2. I am glad this doesn't seem the case with Go.

This is certainly possible (flavours) and I'm totally unwilling to do that, sorry ;)
Haha. Understandable.
 
Well the patch is now updated. Twice, cause, although I really love git, I fucked up first 🤡 – only change is the default options.
 
Thanks to you, too, eternal_noob – but hey, this is off-topic, I just wanted to let the community know why I started to maintain a port and then didn't really maintain it for a while 😔 anyways it's nice to see that ppl understand such things! 👍
 
Wow, sometimes it's damn quick … update landed in the ports tree :cool:

Also had a very nice experience with fvwm3's upstream dev team. Right now, I need GO_MAKE_ARGS= GOBUILD="go build -ldflags=\"-s -w\"" as a workaround in the port to have FvwmPrompt installed stripped (and it's a requirement for a FreeBSD port that all binaries are installed stripped). Upstream was very willing to quickly fix this, so the workaround won't be needed in 1.0.5 ;)
 
Back
Top