#wayland #hikari #stackingwm

Hey all,

I think I mentioned before about resurrecting the hikari wayland compositor (https://hikari.acmelabs.space) which seems not to be in active development.

What I've done is spent quite a bit of time upgrading hikari from wlroots-0.15 -> wlroots-0.19.2

The efforts of this can be seen on this branch:

https://codeberg.org/thomasadam/hikari

On the `ta/wlroots-0.19` branch (the default branch for now in this repo).

If you'd like to use #got, see:

https://thomas.gothub.org/repos/?action=summary&path=hikari.git

This will be kept in sync with codeberg.

I think seems seem mostly working. Testing welcome though!

In addition to upgrading the wlroots version, I've also added the option to use #meson instead of #bmake

Any problems, file an issue on the repo, or speak to me directly.

Unofficially for now, I'm also lurking in the IRC #hikari channel on libera.chat, if that's more convenient.

As you can see the build process is smooth, the execution is blazingly fast. What more could I ask for?

https://smolbsd.org/

#programming #technology #BSD #netBSD #metaOS #microVM #networking #qemu #host #bmake #curl #sshd #Linux

The mighty world of BSD

Playing with again smolBSD, a fantastic metaOS system that I talked about a few weeks ago.
I'm a newbie, a greenhorn, when it comes to meta-operating systems built on top of NetBSD.

I am very eager to learn by doing, making mistakes in the process, correcting and feel the warmth of the BSD community, who is happy to correct, esp when I show that I read the docs after making the mistakes

The journey is fantastic, the learning process is fun. microVM's are amazing. I've registered 11ms boot times on this small machine with a few CPU cores (and 40GB RAM). The fun is endless

#programming #technology #BSD #netBSD #metaOS #microVM #networking #qemu #host #bmake #curl #sshd #Linux

https://smolbsd.org/

Ever considered #bmake as a general purpose programming language? Here's FizzBuzz!

https://codeberg.org/sjmulder/bmake-toys/src/branch/master/fizzbuzz.mk

#AdventOfCode

bmake-toys/fizzbuzz.mk at master

bmake-toys - Programming exercises in bmake

Codeberg.org

It's always nice when you find some obscure feature that happens to be the only way around a thorny problem.

Today that was the "::=str" feature in #bmake, for which the manual page even states "This modifier and its variations are useful in obscure situations such as...".

I needed to lazily evaluate the output of a command, but also have that output shared across other shell instances for the same target. Without ::=str I don't think there was any other way around the problem.

#pkgsrc

Hey everyone, I'm studying #C and planning to contribute to some open-source projects soon. I have a question: in #FreeBSD, do you usually use #gmake, #bmake, or #cmake more frequently? (I'm a beginner, but I got the impression that cmake is the most comprehensive). Is there one that's more universal and can be used across all projects, or does it depend on the project? And for #Emacs, which one helps more with configuration?

@mpts @lobocode I can't fully agree. "Make" is declarative by nature, and a fully declarative Makefile contains nothing but variable expansions and rules with recipes. I *would* agree that #bmake makes it easier to write such a Makefile in many cases for its powerful expansion modifiers (some of which you can't even simulate with gmake's custom functions, like substitutions using regular expressions). But OTOH, it also makes some "procedural" style easier by e.g. providing a "for" loop that runs at parse time (not available in #gmake).

That said, "!=" is a poor replacement for $(wildcard ): "!=" also runs at parse time, $(wildcard ) OTOH is a function only executed when needed for expansion. #bmake offers the "${:!...!}" expansion that would be a better match here (still with the drawback of having to call some external tool of course).

Of course, any "if" (and similar) forces immediate expansion of its arguments in both make flavors, therefore breaking the "pure" declarative style.

@lobocode They're just very different.

#gmake excells in "meta-programming", providing functions (builtin and custom) and the "evil" $(eval ...) (and indeed, code using that is hard to keep at least remotely readable), basically containing a functional programming language. OTOH, it sucks in surprising ways, e.g. it has no idea of numbers/arithmetics. It also has things I'd personally call total "misfeatures", like these default variable values, default rules, even pattern rules can bite you badly ...

Among the strong points of #bmake are many very concise and flexible variable expansion modifiers (including arbitrary replacements, also using regular expressions, and even a "loop expansion").

#FreeBSD makes good use of the nice #bmake features in its build systems (at least base and ports).

@lobocode bmake makes you think about your makefile in a more declarative way. As a result, bmake supports querying Makefiles for the value of a variable, e.g., `bmake -V CC` would give you the value of CC.

Usually, it is possible to express the GNU Make functions with the "!=" assignment in bmake. E.g., when I need an equivalent of GNU Make's `$(wildcard ...)` I tend to use `FOO!= ls *` instead.

#freebsd #bmake #gnu #gmake #makefile

Is there any advantage to using #bmake in #FreeBSD instead of #gmake? I get the impression that gmake allows for more modern directives (like adding multiple files to the SOURCE parameter instead of pointing them out one by one, or having to delete this in a shell). But, I dunno, sometimes that can also be a disadvantage...