cloning current system - opnsense install on test system for bridge hashout - lots of reading still to do #gmake

Ричард Столлман, автор GCC и Emacs: жизнь после «отмены»

Сложно найти человека, про которого ходит больше легенд, чем Ричард Столлман (RMS). Наверное, по количеству невероятных историй и анекдотов с ним могут сравниться только Джефф Дин и его брат Джеки Чан . Причём многие невероятные истории о Столлмане — правда. Например, что он запрашивал веб-страницы wget-демоном по почте (для безопасности) и отказался от использования мобильных телефонов, которые называет портативными устройствами слежения . На своём переделанном ноутбуке Thinkpad x200 он в основном работает в консоли и старается не подключаться к веб-сайтам с собственной машины. В 71 год Столлман борется с раком (успешно) и пострадал от травли за свои спорные высказывания и действия. Но его достижений хватит на десятки или сотни великих жизней. Он является автором компилятора GCC и текстового редактора Emacs , а также основателем проекта GNU, дополнением к которому стало ядро Linux, в результате чего появилась полноценная ОС. Гений Столлмана опередил время. Только в 21 веке — с ползучим наступлением цифрового тоталитаризма, всеобщей слежки в духе «1984» и алгоритмизацией всех аспектов жизни — люди постепенно начинают понимать, что Ричард Столлман был прав .

https://habr.com/ru/companies/ruvds/articles/857666/

#ruvds_статьи #Ричард_Столлман #Richard_Stallman #RMS #отмена #GNU #Linux #Линус_Торвальдс #GNU_Compiler_Collection #GCC #Emacs #поддержание_истины #truth_maintenance #TMS #GNU_Debugger #GDB #копилефт #GPL #GNU_Make #gmake

#frustration

To all those devs, who make their projects hard-depend on a shitty #GNU toolchain, either because you are lazy or for political reasons - please, GO FUCK YOURSELVES. Have a bad day.

#bison #m4 #gmake #autotools #gcc #glibc

@lobocode @meena
PR created: https://github.com/scovl/checkrc/pull/5

Mina, no, not "just your headache", the portable subset of make simply doesn't cut it, and doing complex things in make is possible, but hard and quickly becomes unreadable, that's why well-written frameworks are a nice thing ...

I personally have my very own for #gmake (which I use for all portable stuff). When writing stuff specifically for #FreeBSD, I very much prefer using what's already there.

Adding features in a module with clear boundaries is so much more fun!

I just added different modes for using #Qt's #moc to my new USES=qt in my #gmake framework ... Testing it with #qXmoji (my new #X11 #emoji #keyboard) in the mode that just includes moc-generated stuff, and it works like a charm. No more extra compilation steps for moc, this whole build log now looks nicely short (screenshot: build from entirely clean git checkout) 🥳

https://github.com/Zirias/qxmoji/commit/928bc8a1cc0fd1a54908bda13ba31042ed6b1471

I'm one of these mad guys refusing to pull some "modern" buildsystem (like cmake or meson) into my projects, yet also dislike the complexity and overhead of autotools ... so I created my own "buildsystem" many many years ago, which is basically a #gmake (#GNU #make) framework using "eval" to generate rules on the fly.

Over the years, I piled up features in there as I needed them for current projects. The result is (although it still "worked") chaos. 🙈 More and more, I'm having trouble understanding my own code, and changing things is almost guaranteed to also break things. 🙄

I now decided to refactor a lot, giving some structure to that mess, and took inspiration from #FreeBSD's #ports framework by introducing a "USES" concept to load optional parts. So far, this seems to turn out well, it also gives the opportunity to better document that stuff given the clear responsibility of each USES, see e.g. the one handling installation of freedesktop.org stuff:

https://github.com/Zirias/zimk/blob/master/lib/uses/fdofiles.mk

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...

#gmake (#GNU) or #bmake (#BSD, or other pmake descendant)?

Well, both excel and both suck, just in different areas. 🙈

When I started to build my own #make framework for my own projects, I opted for #gmake, just because it's more widespread and easy to get/install on most platforms.

gmake is strong with functions (even user-defined ones) and together with $(eval ...) can do some impressive meta-programming, even generating its own rules at runtime, although the code will be a bit hard to follow. One of its weaknesses that bother me most is, it doesn't know anything about numbers 😶 A simple thing like "is a greater than b" is close to impossible to answer without calling out to the shell ...

bmake seems quite compact and simple, typical BSD style, still with some strong features, e.g. very flexible variable expansions. It can do loops in a simple straight-forward way. bmake code tends to be more readable for more complex stuff, but also often a lot more verbose.

Added 𝗨𝗣𝗗𝗔𝗧𝗘 𝟭 - 𝗟𝘂𝗮 𝗮𝗻𝗱 𝗚𝗲𝗻𝗲𝗿𝗮𝗹 𝗣𝘂𝗿𝗽𝗼𝘀𝗲 𝗟𝗮𝗻𝗴𝘂𝗮𝗴𝗲 𝗦𝗲𝗿𝘃𝗲𝗿𝘀 to the 𝗣𝗲𝗿𝗳𝗲𝗰𝘁 𝗡𝗲𝗼𝘃𝗶𝗺 𝗔𝗻𝘀𝗶𝗯𝗹𝗲 𝗦𝗲𝘁𝘂𝗽 article.

https://vermaden.wordpress.com/2024/03/13/perfect-neovim-ansible-setup/#comments

#ansible #editor #freebsd #ide #linux #make #gmake #neovim #nvim #pkg #playbook #YAML

If you #RUNBSD and desperately want to avoid the #GNU, you end up with certain issues. That is so unnecessary... Why not just accept #gmake, what's the big deal? Can someone explain, maybe even an #OpenBSD user specifically?

https://twitter.com/FreeBSDHelp/status/1154667590481879041?s=19