@peppe There's generally very little need to build from ports yourself when binary packages are available for your target architectures. Some people still like the (IMHO flawed) idea that building everything with "optimizing" CFLAGS (e.g. targeting the specific CPU) would result in better overall performance. That's been historically a widespread idea among Gentoo users. In reality, there's very little code that could significantly profit from that, and for code that does, there's typically a better solution already in place, like runtime CPU detection. And it comes with tons of potential issues, breaking lots of things. So, the only sensible need for building yourself would be when you need non-default port options and similar.
The next issue is, you can easily break stuff by just mixing ports and packages, most obviously because the packages were build from a different state of the ports tree, but also incompatible options can lead to issues.
Therefore, if you really want to build yourself, I recommend setting up poudriere. You'll probably find lots of guides. If you use the "poudriere-devel" package, you get a newer version that can just fetch binary packages *when* they perfectly match what you build, saving you a lot of time for building a whole package repository.
@peppe Only very few ports are never built by the package builders, typically for legal reasons. ungoogled-chromium is not one of them. On freshports, you'll find a table with available binary packages of every port. For ungoogled-chromium, it's currently indeed missing, and the most likely reason can be seen here:
https://portsfallout.com/fallout?port=www%2Fungoogled-chromium%24
(There's a very recent build failure on amd64 for latest).
Regarding wayland, it's no doubt great to have software reliably ported, but I really dislike the whole concept, part of which is there can't be a "window manager", because you have to implement a compositor instead, responsible for the final compositing of windows, and all rendering of window contents is delegated to each and every client ... both things the X server can do for you. My personal "resistance" was to learn last year how to create an X client "from scratch" (without toolkits) and actually use the rendering facilities X has to offer 😏
@peppe Well, #dwm is a window manager. Then there's #dwl, which is a #wayland #compositor, trying to do "functionally the same" as dwm. My point is, it has to implement a lot more stuff to do so.
My favorite window manager is #fvwm (or now #fvwm3), and as far as I know, its main developer was looking into wayland and currently doesn't have any concrete plans to work on that ... and I can perfectly understand. 😔
@peppe To be clear about that, I don't question the fact that #X11 is full of old cruft that's mostly useless nowadays. It became more than clear to me while implementing my #xmoji tool, which uses almost exclusively #XRender requests for rendering (an *extension* to X11, not part of the core protocol), because X core drawing requests are really designed for 1990es hardware, supporting color palettes with limited entries, but no alpha channel whatsoever. Similar goes for font support in the X11 core protocol, it's useless supporting only bitmap fonts with no antialiasing etc, so I use client-side rasterizing (with freetype) and XRender only for compositing the result. There are more silly examples, like the "Compound Text" encoding monstrosity, because the core design predates Unicode, and so on....
In a nutshell, a major rework of what the X core protocol supports would be necessary.
But then, you can *still* dislike a suggested solution. I think #wayland is taking the "simplicity" much too far, so now both compositors and clients (rendering windows) have to do the same stuff over and over again. It's a pointless exercise trying to create a wayland client without huge libraries (such as e.g. cairo for client-side rendering, better yet use a full-blown toolkit like Qt or GTK that already makes use of cairo), while this is perfectly possible for X.
@thomasadam @peppe Thanks for that! I totally forgot about the decorations topic, which is of course very relevant, it means even jumping through the hoop and implementing a #wayland compositor, you can only deliver part of the functionality (and almost none of the looks) of your window manager.
But even with that issue solved, I would really dislike wayland's design. Although I *do* think that most of #X11 core drawing is obsolete and useless (mostly for the missing alpha channel), I think a display server should offer drawing facilities. Replace X with something dropping lots of cruft (indexed palettes, COMPOUND_TEXT, etc), instead incorporate extensions that everyone needs these days, extend #XRender (now as part of core) to offer more drawing primitives, etc ... you could have a replacement for X11 that's worth dealing with. And window managers could still be separate clients.
@zirias @peppe Yeah, the design of Wayland precludes a lot of the niceities from X11; you can see it in how pervasive and, frankly stupid, some of the Wayland protocol coversatioms happen with repect to things like adding an application icon.
It's seriously a huge regression.
What they need is the EWMH -- but what they're getting is bike-shedding.
Thankfully, not my problem. :)
thesaigoneer
Felix Palmen 
Thomas Adam