"The new alternative does no such sleight of hand. Instead, it just gets the systemd daemon to run the command for you, using a special form of the existing systemd-run command." Sounds like a new path for exploits. We'll see if Mr Systemd has to eat some crow in the future. Said by a guy who _hates_ systemd.

IMO systemd, was >>not<< a net positive - it falls so many of these tests WRT to good programming and good ideas.

Are there any known attempts in the modern age to roll Linux with something resembling research/BSD init? That would be a nice counter to the proliferation of systemd.

On Thursday, June 13th, 2024 at 9:47 AM, Arrigo Triulzi via TUHS &lt;tuhs(a)tuhs.org&gt; wrote: Part of what irks me is the lack of choice. Just like many outlets will use GNU extensions to otherwise POSIX components, leaving the rest of the world out in the rain, several bits of the Linux ecosystem have backed systemd as the one true way and are hobbled if even usable at all with other init systems out there. User software shouldn't have any attachment to a particular init system, it isn't meant to provide "services" beyond run this script at this time based on the conditions of boot, manage terminal lines, and maybe offer some runlevels to compartmentalize operating environments. I've seen it said elsewhere that the amount of surface area being shoved into PID 1 can only lead to disaster.

Are there any known attempts in the modern age to roll Linux with something resembling research/BSD init?

That would be a nice counter to the proliferation of systemd. Even if it doesn't make a dent in the actual uptake, at least it'd feel cathartic to have an alternative in the opposite direction.

[snip] If your daemon's are crashing and in need of restarting so often that a tool is needed to restart them then you have a myriad of other far more pressing problems you should be dealing with first!

If it were so simple I would expect that claim to be more widely advertised, yet we fall back on "it restarts daemons that crash".

Personally I think systemd trying to solve the rather high demands and diverse requirements of mobile laptop systems and is trying to meet or match MS Windows in this regard. (personally I think macos has them both beat by a country mile!) It sure as heck isn't of any use in production server environments!

If it were more about servers then it would look more like SMF, or maybe launchd, and it's code wouldn't look like it was written by a grade school student.

I may be in a bit of a grumpy mood, so forgive me if this is snarkier than I intend, but statements like this bother me.

Second, there are many reasons beyond just "lol it crashed" that you may want to restart dependent services; for example, perhaps you are upgrading a system and part of the upgrade process is restarting your dependents. Having a system that does things like that for you is useful.

Grant Taylor via TUHS &lt;tuhs(a)tuhs.org&gt; writes: Indeed: it doesn't just do init, but also _service supervision_ (making sure that a service that _should_ be up, _is_ up) and _service management_ (enabling, disabling, starting, stopping, dependencies, etc.). Hence why phrases like "the init wars" are such a misnomer. As described in the potted history outlined in the "known problems with System 5 rc" article i linked to upthread, Sys V rc's issues with service supervision and service management have been known for decades: The initial release of OpenRC - still Gentoo's 'native' system for service management - was in April 2007; the initial release of systemd was in March 2010. But although both OpenRC and systemd address various pain points of Sys V rc on Linux, systemd has _also_ had the backing of an 800-pound gorilla in the Linux world - Red Hat - which has _implicitly_ forced its adoption over alternatives by distros that don't have the same level of resources behind them. Here's an excerpt from something i wrote on the Gentoo forum back in April: Alexis.

In the "Unix world" everyone learns shell scripting, some better than others of course, and some hate it at the same time too, but I would say from my experience it's a given. You either learn shell scripting or you are "just a user" (even if you also write application code).

Algol has been a dead language for many years, for good reasons too. their bookshelf at work and what books they have read. with some of the new hires (from really good schools, too), and it was worse because they often had never seen the true Bourne shell (nor knew much/anything about Algol, much less A68). Many thought "bash" was the UNIX shell because they never knew better (chuckle). I realized it was a huge hole in their education, so I got my admin to order each copies of K&R2 and UPE for their desks. I said I expected them to do the exercises in them as part of their "training." I could usually tell a lot about each person by the questions they asked during that period. Many often griped about having to learn to use ed and nroff. I think those that were already EMACS folks thought I was a little bonkers but my comment was that you'll understand the other tools better/be a lot more effective with the shell in particular. Many had seen Latex, so the >>idea<< of a document compiler was not always completely foreign. But they crawled through each book. were much better with the UNIX tool kit after UPE, and because they actually read K&R2, they often learned a few things about C they never realized. Once they "graduated" also I gave them a copy of APUE, if they were doing networking stuff, UNP too. Most would start doing the APUE and UNP problems also as I would get some of them coming to my office with questions, but I never said they had to do them. Peter Yardley peter.martin.yardley(a)gmail.com

"Greg A. Woods" &lt;woods(a)robohack.ca&gt; writes: i feel this comment is unfair. The specific thing i wrote was: [emphasis added] The issue isn't about learning shell scripting _per se_. It's about the extent to which _volunteers_ have to go beyond the _basics_ of shell scripting to learn about the _complexities_ and _subtle issues_ involved in using it to provide _robust_ service management. Including learning, for example, that certain functionality one takes for granted in a given shell isn't actually POSIX, and can't be assumed to be present in the shell one is working with (not to mention that POSIX-compatibility might need to be actively enabled, as in the case of e.g. ksh, via POSIXLY_CORRECT). Here's a FreeBSD thread from 2014, about how service(8) wasn't providing the same environment to scripts that boot did: https://lists.freebsd.org/pipermail/svn-src-head/2014-July/060519.html i'm a BSD user as well as a Linux user - i've been maintaining OpenBSD servers for several years. i certainly have my own criticisms of Linux versus OpenBSD - for example, i'm, mm, 'not a fan' of the somewhat cavalier attitude towards documentation that can often be found in the Linux world, so i'm grateful for people like Alejandro Colomar and his extensive work on the Linux man-pages project. But i feel the above thread suggests that either the FreeBSD devs are clueless about shell scripting or - as i feel is actually the case - that service management via shell scripting isn't as straightforward as one might assume.

On Mon, Jun 17, 2024 at 11:01:40AM +1000, Alexis wrote: in shell one is This is sort of off topic but maybe relevant. When I was running my company, my engineers joked that if it were invented after 1980 I wouldn't let them use it. Which wasn't true, we used mmap(). But the underlying sentiment sort of was true. Even though they were all used to bash, I tried very hard to not use bash specific stuff. And it paid off, in our hey day, we supported SCO, AIX, HPUX, SunOS, Solaris, Tru64, Linux on every architecture from tin to IBM mainframes, Windows, Macos on PPC and x86, etc. And probably a bunch of other platforms I've forgotten. *Every* time they used some bash-ism, it bit us in the ass. I kept telling them "our build environment is not our deployment environment". We had a bunch of /bin/sh stuff that we shipped so we had to go for the common denominator.

really wanted and that is build environment, so, shrug.

On 2024-06-16 21:25, Larry McVoy wrote (in part): [...] This is so true for a lot of OS projects (on Github, for example). Most -- sometimes all -- the scripts that start with /bin/sh but are full of bashisms because the authors run systems where /bin/sh is really bash.

Which is why I'm glad Debian's /bin/sh is dash (fork of ash) instead.

Once it morphed organically for even 5 years, going back was hard. There was no upstream anymore. Csrg was gone, and all successor BSD projects assumed they were the new upstream. It was rarely clear whichnproject has the rights to that claim as the answer was patjologically different for different parts of the system.

On 19 Jun 2024, at 08:44, Greg A. Woods &lt;woods(a)robohack.ca&gt; wrote: At Mon, 17 Jun 2024 17:44:40 -0600, Warner Losh &lt;imp(a)bsdimp.com&gt; wrote: Subject: [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register Hmmm.... I never really thought of it that way before! I guess I had hoped everyone would come to realize a new one-size-fits-all upstream would be a "good thing", or perhaps even a necessity, and that none would automatically slip into thinking they were it without first reaching some consensus with other projects

On Sun, 16 Jun 2024, Greg A. Woods wrote: It's still possible to port NetBSD's /bin/sh to Debian (I've done it, called it "nash", but don't have any official release because I don't really see a point). And it's basically the "sh" I'm currently using in my projects because I don't have the talent to write my own. :P -uso.

At Tue, 18 Jun 2024 04:52:51 +0000, segaloco via TUHS &lt;tuhs(a)tuhs.org&gt; wrote: Subject: [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register Oh, that strikes a nerve. CMake is the very antithesis of a good tool. It doesn't help. I think it is perhaps the worst abomination EVER in the world of software tools, and especially amongst software construction tools.

Greg A. Woods &lt;gwoods(a)acm.org&gt; Kelowna, BC +1 250 762-7675 RoboHack &lt;woods(a)robohack.ca&gt; Planix, Inc. &lt;woods(a)planix.com&gt; Avoncote Farms &lt;woods(a)avoncote.ca&gt;

On Tue, Jun 18, 2024, 4:50 PM Greg A. Woods &lt;woods(a)robohack.ca&gt; wrote: Someone clearly never used imake...

On Tue, Jun 18, 2024, 7:38 PM Greg 'groggy' Lehey &lt;grog(a)lemis.com&gt; wrote: Cmake actually works though...

"Greg A. Woods" &lt;woods(a)robohack.ca&gt; wrote: I'm not a fan of cmake either. How do you deal with software that only builds with cmake (or meson, scons, ... whatever the developer decided to use as the build tool)? What alternatives exist short of reimplementing the build process in a standard makefile by hand, which is obviously very time consuming, error prone, and will probably break the next time you want to update a given package? If there is some great alternative, I would like to know about it. scot

"Greg A. Woods" &lt;woods(a)robohack.ca&gt; wrote: I'm not a fan of cmake either. How do you deal with software that only builds with cmake (or meson, scons, ... whatever the developer decided to use as the build tool)? What alternatives exist short of reimplementing the build process in a standard makefile by hand, which is obviously very time consuming, error prone, and will probably break the next time you want to update a given package?

Someone clearly never used imake... There's a reason that the xmkmf command ends in the two letters it does, and I'm never going to believe it's "make file". Adam On Thu, Jun 20, 2024 at 11:34 AM Greg A. Woods &lt;woods(a)robohack.ca&gt; wrote:

In general, in my experience, autoconf makes for less portability, not more.

The slurm configure, produced by the configure script, is 1 mbyte, 30,000 lines of impenetrable script. For each .c file in slurm, an 11960 line libtool script is invoked. autoconfig uses m4. When I told Eric Grosse, back in 2015, that *anything* still used m4, he would not believe it was "the m4 from the 70s" until I showed him. He was speechless. He had assumed m4 died in the 80s. Personally, the autoconfig process does not fill me with confidence, and it was recently responsible for a very serious security problem. And, autoconfig doesn't work: I've lost track of how many times autoconf has failed for me. In general, in my experience, autoconf makes for less portability, not more. For a good example of a very portable system with a very clean, human-readable make setup, I'd recommend a look at plan9ports. It includes 2 window managers, 2 graphical editors, and all the Plan 9 tools, and somehow manages to be at least as portable as the autoconf mechanism. On Thu, Jun 20, 2024 at 12:59 PM Warner Losh &lt;imp(a)bsdimp.com&gt; wrote: > For me, precomputing an environment is the same as a wysiwyg editor: what > you see is all you get. If it works for you, and the environment that's > inferred from predefined CPP symbols is correct, then it's an easy > solution. When it's not, and for me it often wasn't, it's nothing but pain > and suffering and saying MF all the time (also not Make File).... I was > serious when I've said I've had more positive cmake experiences (which > haven't been all that impressive: I'm more impressed with meson in this > space, for example) than I ever had with IMakefiles, imake, xmkmf, etc... > But It's also clear that different people have lived through different > hassles, and I respect that... > > I've noticed too that we're relatively homogeneous these days: Everybody > is a Linux box or Windows Box or MacOS, except for a few weird people on > the fringes (like me). It's a lot easier to get things right enough w/o > autotools, scons, meson, etc than it was in The Bad Old Days of the Unix > Wars and the Innovation Famine that followed from the late 80s to the mid > 2000s.... In that environment, there's one of two reactions: Test > Everything or Least Common Denominator. And we've seen both represented in > this thread. As well as the 'There's so few environments, can't you > precompute them all?' sentiment from newbies that never bloodied their > knuckles with some of the less like Research Unix machines out there like > AIX and HP/UX... Or worse, Eunice... > > Warner > > On Thu, Jun 20, 2024 at 12:42 PM Adam Thornton &lt;athornton(a)gmail.com&gt; > wrote: > >> >> >> Someone clearly never used imake... >> >> >> There's a reason that the xmkmf command ends in the two letters it >> does, and I'm never going to believe it's "make file". >> >> Adam >> >> On Thu, Jun 20, 2024 at 11:34 AM Greg A. Woods &lt;woods(a)robohack.ca&gt; >> wrote: >> >>> At Thu, 20 Jun 2024 01:01:01 -0400, Scot Jenkins via TUHS < >>> tuhs(a)tuhs.org&gt; wrote: >>> Subject: [TUHS] Re: Version 256 of systemd boasts '42% less Unix >>> philosophy' The Register >>> > >>> > "Greg A. Woods" &lt;woods(a)robohack.ca&gt; wrote: >>> > >>> > > I will not ever allow cmake to run, or even exist, on the machines I >>> > > control... >>> > >>> > I'm not a fan of cmake either. >>> > >>> > How do you deal with software that only builds with cmake (or meson, >>> > scons, ... whatever the developer decided to use as the build tool)? >>> > What alternatives exist short of reimplementing the build process in >>> > a standard makefile by hand, which is obviously very time consuming, >>> > error prone, and will probably break the next time you want to update >>> > a given package? >>> >>> The alternative _is_ to reimplement the build process. >>> >>> For example, see: >>> >>> https://github.com/robohack/yajl/ >>> >>> This example is a far more comprehensive rewrite than is usually >>> necessary as I wanted a complete and portable example that could be used >>> as the basis for further projects. >>> >>> An example of a much simpler reimplementation: >>> >>> >>> http://cvsweb.NetBSD.org/bsdweb.cgi/src/external/mit/ctwm/bin/ctwm/Makefile… >>> >>> -- >>> Greg A. Woods &lt;gwoods(a)acm.org&gt; >>> >>> Kelowna, BC +1 250 762-7675 RoboHack &lt;woods(a)robohack.ca&gt; >>> Planix, Inc. &lt;woods(a)planix.com&gt; Avoncote Farms &lt;woods(a)avoncote.ca&gt; >>> >>

Personally, the autoconfig process does not fill me with confidence, and it was recently responsible for a very serious security problem. And, autoconfig doesn't work: I've lost track of how many times autoconf has failed for me. In general, in my experience, autoconf makes for less portability, not more.

On Fri, 21 Jun 2024 at 11:47, Chet Ramey via TUHS &lt;tuhs(a)tuhs.org <mailto:tuhs@tuhs.org>> wrote: On 6/20/24 4:12 PM, ron minnich wrote: and it I'd be interested in some examples of this. I've had pretty decent success with autoconf-based portability. I think it's important to make a distinction between autotools not working and  the actual software distribution not being buildable. For example, I've recently been working with Ultrix V4.5.  Most configure scripts are able to complete successfully with ksh or sh5, so I don't absolutely need bash (even though I do have it and use it).  The difficulties begin when trying to compile the actual code; for example, Ultrix doesn't have strdup().

Sure, and I don't disagree. I was just using an old OS to make a point about corner cases; it would be just as applicable if I had a modern OS that for whatever reason lacked strdup(), or your personal favorite "but everyone has this!" function. You're not going to be able to cover all bases all the time, and I'm sure that there are plenty of code authors who aren't interested in formally supporting anything outside of the most common operating systems. If their autotools-based projects work on my other OS that's great, but it isn't the fault of autotools if the project isn't coded with my OS in mind.

On Fri, 21 Jun 2024 at 12:24, Chet Ramey &lt;chet.ramey(a)case.edu&gt; wrote: If their autotools-based projects work on my other OS that's great, but it isn't the fault of autotools if the project isn't coded with my OS in mind.

As well as the 'There's so few environments, can't you precompute them all?' sentiment from newbies that never bloodied their knuckles with some of the less like Research Unix machines out there like AIX and HP/UX... Or worse, Eunice...

I agree that there are certainly times when CMake's leverage has solved problems for people. My most visceral reactions were mostly based on cases where no tool like CMake was really required at all, but CMake had wormed its way into the consciousness of new programmers who never learned make, and thought CMake was doing them a great service. Bugged the hell out of me, this dumbing-down of the general programming population. My bad experiences were all as a consultant to teams that needed a lot of expert help, when they had thrown CMake along with a lot of other unnecessary complexity into their half-working solutions. So I guess it was all tarred by the same flavor of badly conceived work. But then as I tried to make my peace with the CMake build as it was, I got a deeper understanding of how intrinsically irrational CMake is (and again, behavior changing on the same builds depending on CMake release versions. So there certainly are times when something a little more comprehensive, outside of make, is required. ./configure && make is not so bad, it's not irrational, sometimes it's overkill, but it works ... but only if the system is kind of Unix-y. If not you may wind up doing a lot of work to pretend it's more Unix-y, so instead of porting your software, you're porting it to a common Unix-like subset, then emulating that Unix-like subset on your platform, both ends against the middle. That can be ultimately counter-productive too. I have an emotional reaction when I see the porting problem become transformed into adherence to the "one true way", be it Unix, or one build system or another. Because you're now just re-casting the problem into acceptance of that other tool or OS core as the way it should be. Instead of getting your thing to work on the other platform, by translating from what your application wants, into how to do it on whatever system, you're changing your application to be more like what the "one true system" wants to see. You've given up control of your idea of your app's core OS requirements, you've decided to "just give in and be UNiX (or Windows, or whatever)". To me, that's backwards. On 06/20/2024 12:59 PM, Warner Losh wrote: For me, precomputing an environment is the same as a wysiwyg editor: what you see is all you get. If it works for you, and the environment that's inferred from predefined CPP symbols is correct, then it's an easy solution. When it's not, and for me it often wasn't, it's nothing but pain and suffering and saying MF all the time (also not Make File).... I was serious when I've said I've had more positive cmake experiences (which haven't been all that impressive: I'm more impressed with meson in this space, for example) than I ever had with IMakefiles, imake, xmkmf, etc... But It's also clear that different people have lived through different hassles, and I respect that... I've noticed too that we're relatively homogeneous these days: Everybody is a Linux box or Windows Box or MacOS, except for a few weird people on the fringes (like me). It's a lot easier to get things right enough w/o autotools, scons, meson, etc than it was in The Bad Old Days of the Unix Wars and the Innovation Famine that followed from the late 80s to the mid 2000s.... In that environment, there's one of two reactions: Test Everything or Least Common Denominator. And we've seen both represented in this thread. As well as the 'There's so few environments, can't you precompute them all?' sentiment from newbies that never bloodied their knuckles with some of the less like Research Unix machines out there like AIX and HP/UX... Or worse, Eunice... Warner On Thu, Jun 20, 2024 at 12:42 PM Adam Thornton &lt;athornton(a)gmail.com&gt; wrote:

it's not irrational, sometimes it's overkill, but it works" Never? Any tool can be misused (perhaps there’s an issue with slurm’s implementation here?) I think the quality of autoconf usage (by project authors) has declined, perhaps as building from source has been overtaken by the use of binary packages. I’d argue that autotools (incl automake and libtool) can be a decent solution in the hands of devs who care. At one time, I think it was the best compromise, although I’m open to argument that this time has passed. It was certainly never useful for general portability to Windows, for instance, and more recent tools manage that better. d

here's where I'd have to disagree: "./configure && make is not so bad, it's not irrational, sometimes it's overkill, but it works" because it doesn't. Work, that is. At least, for me. I'm amazed: the autoreconf step on slurm permanently broke the build, such that I am having to do a full git reset --hard and clean and start over. Even simple things fail with autoconf: see the sad story here, of how I pulled down a few simple programs, and they all fail to build. I replaced them ALL with a single Go program that was smaller, by far, than a single one of the configure scripts. https://docs.google.com/presentation/d/1d0yK7g-J6oITgE-B_odadSw3nlBWGbMK7cl… On Thu, Jun 20, 2024 at 1:35 PM Luther Johnson &lt;luther.johnson(a)makerlisp.com <mailto:luther.johnson@makerlisp.com>> wrote: I agree that there are certainly times when CMake's leverage has solved problems for people. My most visceral reactions were mostly based on cases where no tool like CMake was really required at all, but CMake had wormed its way into the consciousness of new programmers who never learned make, and thought CMake was doing them a great service. Bugged the hell out of me, this dumbing-down of the general programming population. My bad experiences were all as a consultant to teams that needed a lot of expert help, when they had thrown CMake along with a lot of other unnecessary complexity into their half-working solutions. So I guess it was all tarred by the same flavor of badly conceived work. But then as I tried to make my peace with the CMake build as it was, I got a deeper understanding of how intrinsically irrational CMake is (and again, behavior changing on the same builds depending on CMake release versions. So there certainly are times when something a little more comprehensive, outside of make, is required. ./configure && make is not so bad, it's not irrational, sometimes it's overkill, but it works ... but only if the system is kind of Unix-y. If not you may wind up doing a lot of work to pretend it's more Unix-y, so instead of porting your software, you're porting it to a common Unix-like subset, then emulating that Unix-like subset on your platform, both ends against the middle. That can be ultimately counter-productive too. I have an emotional reaction when I see the porting problem become transformed into adherence to the "one true way", be it Unix, or one build system or another. Because you're now just re-casting the problem into acceptance of that other tool or OS core as the way it should be. Instead of getting your thing to work on the other platform, by translating from what your application wants, into how to do it on whatever system, you're changing your application to be more like what the "one true system" wants to see. You've given up control of your idea of your app's core OS requirements, you've decided to "just give in and be UNiX (or Windows, or whatever)". To me, that's backwards. On 06/20/2024 12:59 PM, Warner Losh wrote:

On 19 Jun 2024, at 09:03, Warner Losh &lt;imp(a)bsdimp.com&gt; wrote: Someone clearly never used imake...

At Tue, 18 Jun 2024 04:52:51 +0000, segaloco via TUHS &lt;tuhs(a)tuhs.org&gt; wrote: Subject: [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register Oh, that strikes a nerve. CMake is the very antithesis of a good tool. It doesn't help. I think it is perhaps the worst abomination EVER in the world of software tools, and especially amongst software construction tools. -- Greg A. Woods &lt;gwoods(a)acm.org&gt; Kelowna, BC +1 250 762-7675 RoboHack &lt;woods(a)robohack.ca&gt; Planix, Inc. &lt;woods(a)planix.com&gt; Avoncote Farms &lt;woods(a)avoncote.ca&gt;

On Tue, Jun 18, 2024 at 7:09 PM Luther Johnson &lt;luther.johnson(a)makerlisp.com&gt; wrote: That's a really bold claim. You may not like the solution (I don't tend to comment on it because unlike some here, I recognize that build systems are a Hard Problem and I don't know how to make a better solution), but that doesn't mean it isn't solving real problems. But I'll bite. There was the claim by Larry McVoy that "Writing Makefiles isn't that hard". Please show these beautiful makefiles for a non-toy non-trivial product (say, something like gcc or llvm), which make it easy to change platforms, underlying compilers, works well with modern multicore processors, gets the dependencies right (one should never have to type "make clean" to get a build working correctly), etc. and doesn't require blindly running some 20K line shell script like "configure" to set it up. -- Nevin ":-)" Liber <mailto:nliber@gmail.com> +1-847-691-1404

I don't think any makefiles I've written do all of that. I guess I don't expect all of that in one place. So i will have some makefiles that are really portable, because they are very compute-bound or their interface to the world is something else generic, like files. And then for more platform-specific parts I would have different makefiles for different platforms. One-button, one command-build (that seems) identical for all platforms, is not that important to me. And yes, sometimes I write scripts to do the parts of a build in sequence. And I don't consider any of this 'hard', but I'm not trying make the builds look like they are the same, even if they are really quite different. The GNU ./configure, make model is one model. CMake and other makefile generators are another. But I have used several compilers or other general purpose tools that have more than one makefile or build script, depending on the platform, and I just take the tool for what it is, and use it. And when I have to debug or change something about the build, it's MUCH easier to work with makefiles and build scripts than it is to extend configure scripts, or extend a build-specification in a build-tool-specific language. In my experience, so far. But some people will get into configure and/or CMake or any of the others and learn how to be productive that way. More power to them, but I don't enjoy doing that. When I have had to use CMake, it seemed to require more specification on my part to generate all sorts of crufty state, so every build was not necessarily the same, unless I used the right commands or deleted all these extra directories full of persistence from the last CMake or build, to write all these weird, generated, unreadablemakefiles calling makefiles, doing no more than I could easily do by hand in one makefile. No, my hand-written makefiles will not be absolutely universal, or appear to be, but they will work in a way I can predict, and that is of great value to me. On 06/18/2024 05:46 PM, Nevin Liber wrote:

and I can't really see what CMake does for me that I can't do for myself.

And when I have to debug or change something about the build, it's MUCH easier to work with makefiles and build scripts than it is to extend configure scripts, or extend a build-specification in a build-tool-specific language. In my experience, so far.

On Tue, Jun 18, 2024 at 07:46:15PM -0500, Nevin Liber wrote: Makefiles Works on *BSD, MacOS, Windows, Linux on a bunch of different architectures, Solaris, HPUX, AIX, IRIX, Tru64, etc.

# Licensed under the Apache License, Version 2.0 (the "License"); # you may not use this file except in compliance with the License. # You may obtain a copy of the License at # http://www.apache.org/licenses/LICENSE-2.0 # Unless required by applicable law or agreed to in writing, software # distributed under the License is distributed on an "AS IS" BASIS, # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. # See the License for the specific language governing permissions and # limitations under the License. # Makefile for BitKeeper. # Bitmover makefiles try to provide the following targets: # # all build everything under the current directory # # clean remove all objects and programs # # clobber run clean plus 'bk -r. clean' # # srcs bk get all sources in current directory # # tags build ctags for all srcs (only needed in this (top) makefile) # # tags.local build ctags for srcs under current directory relative to top # #--- # Special make variables commonly used this makefile: # $@ target # $^ all sources # $< first source INSTALLED_BK ?= $(shell bash -c "cd / && command -v bk") INREPO ?= $(shell bash -c "test -d ../.bk && echo true || echo false") HERE := $(shell pwd) ROOT := $(shell dirname $(HERE)) REPO := $(notdir $(ROOT)) URL := $(shell echo bk://work/$(ROOT) | sed s,/home/bk/,,) LOG = $(shell echo LOG-`bk getuser`) OSTYPE := $(shell bash -c 'echo $$OSTYPE') include conf.mk ## Which hosts are used for producing nightly builds NIGHTLY_HOSTS := macos106 win7-vm debian40 debian40-64 ifeq "$(OSTYPE)" "msys" SYS=win32 EXE=.exe XTRA=win32 ifeq (,$(INSTALLED_BK)) # BINDIR should really be :C:/Program Files/BitKeeper # The shell can not handle space in pathname, so # we use the short name here BINDIR := "C:/PROGRA~1/BITKEE~1" else BINDIR := $(shell bk pwd -s "`bk _registry get 'HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion' ProgramFilesDir`/BitKeeper") endif INSTALL=installdir RESOURCE=bkres.o UWT_C=$(patsubst %,win32/uwtlib/%.c, wapi_intf wcrt_intf) BKGUI=bkg$(EXE) BKG_O=bkg.o else SYS=unix EXE= # You can set this to anywhere you like and do a # build production" and you'll have an installed BitKeeper. ifeq (,$(INSTALLED_BK)) BINDIR := /usr/local/bitkeeper else BINDIR := $(shell "$(INSTALLED_BK)" bin) endif INSTALL=install RESOURCE= endif # By default, we don't print verbose output. If you want to see # the full compiler command line, use 'make V=1' # The trick is to do "$(Q)$(CC)" instead of just "$(CC)" so that if # Q is not set, it's just "$(CC)" and if Q is set to @ it becomes # a quiet "@$(CC)". # For the verbose messages, gmake provides # $(if $(Q),<then>,<else>) # so we just conditionalize on Q. Empty is false. ifndef V Q=@ export Q endif BK=./bk$(EXE) G =-g TRIAL =0 IMGDIR =$(HERE)/tmp/bitkeeper # Handle warning arguments in GCC # # -Wall enables a bunch of warnings by default # -Wno-parentheses shuts up "suggest parentheses around assignment ...". # Unfortunately it also turns off dangling else warnings. # -Wno-char-subscripts shuts up "subscript has type char", which comes # up all the time with broken <ctype.h> implementations. # (renabled in GCC3 since it supresses warnings in system files by default) # -Wno-format-y2k supresses complains about '%y' in strftime formats # -Wstrict-prototypes Don't allow non-ansi function declarations WARNINGS=-Wall -Wno-parentheses -Wno-char-subscripts -Wno-format-y2k \ -Wstrict-prototypes # Warnings enabled with GCC newer than 3.0 # # -Wredundant-decls Declaring same function twice # -Wmissing-declarations Functions without a prototype WARNINGS_GCC3=-Wchar-subscripts -Wredundant-decls -Wmissing-declarations # Warnings enabled with GCC newer than 4.0 # # -Wextra enable a bunch of random things (called -Wextra in newer gccs) # -Wno-pointer-sign Suppress warnings about changing the signs of pointers # -Wno-sign-compare Suppress warnings about comparing signed and unsigned vars # -Wno-unsed-parameter Support warnings about function parameters that are # no used # -Wno-missing-field-initializers # -Wdeclaration-after-statement Warn if someone does a C++ thing of declaring # a variable in the middle of a block WARNINGS_GCC4=-Wextra -Wno-pointer-sign -Wno-sign-compare \ -Wno-unused-parameter -Wno-missing-field-initializers \ -Wdeclaration-after-statement -Wpointer-arith # Warnings enabled with GCC newer than 5.0 # # -Wno-unusedr-esult Do not warn if a caller ignores return value WARNINGS_GCC5=-Wno-unused-result WARNINGS_GCC6= -Wno-misleading-indentation # XXX could not get -Wimplicit-fallthrough=3 to work WARNINGS_GCC7= -Wno-implicit-fallthrough # Other options to consider enabling in the future: # # -Wnested-externs Prototypes declared in a function # -Wwrite-string warn in string constant is passed to a char * # -Wmissing-prototypes # -Wunused-parameter # -Wold-style-definition Would be nice, but zlib falls all over here GCC_MAJOR_REV=$(shell $(CC) -dumpversion | sed 's/\..*//') GCC_MINOR_REV=$(shell $(CC) -dumpversion | sed 's/.*\.//') ifeq ($(GCC_MAJOR_REV),3) WARNINGS += $(WARNINGS_GCC3) endif ifeq ($(GCC_MAJOR_REV),4) WARNINGS += $(WARNINGS_GCC3) $(WARNINGS_GCC4) ifeq ($(shell expr $(GCC_MINOR_REV) \> 5), 1) WARNINGS += -Wno-unused-result endif endif ifeq ($(GCC_MAJOR_REV),5) WARNINGS += $(WARNINGS_GCC3) $(WARNINGS_GCC4) $(WARNINGS_GCC5) endif ifeq ($(GCC_MAJOR_REV),6) WARNINGS += $(WARNINGS_GCC3) $(WARNINGS_GCC4) $(WARNINGS_GCC5) \ $(WARNINGS_GCC6) endif ifeq ($(GCC_MAJOR_REV),7) WARNINGS += $(WARNINGS_GCC3) $(WARNINGS_GCC4) $(WARNINGS_GCC5) \ $(WARNINGS_GCC6) $(WARNINGS_GCC7) endif ifeq ($(GCC_MAJOR_REV),8) WARNINGS += $(WARNINGS_GCC3) $(WARNINGS_GCC4) $(WARNINGS_GCC5) \ $(WARNINGS_GCC6) $(WARNINGS_GCC7) $(WARNINGS_GCC8) endif TRACE = -DUSE_TRACE ifeq ($(shell uname -s), Darwin) XLIBS += -lresolv G += -DNOPROC endif ifeq (clang, $(findstring clang, $(shell $(CC) --version))) WARNINGS += -Wno-unused-value -Wno-empty-body -Wno-self-assign endif GCCOPTS= CC_DEBUG=$(GCCOPTS) $G $(WARNINGS) $(TRACE) CC_FAST_DEBUG=$(GCCOPTS) $G -O2 $(WARNINGS) $(TRACE) CC_FAST =$(CC_FAST_DEBUG) CC_WALL=$(GCCOPTS) $G -DLINT $(WARNINGS) $(TRACE) BINS = $(BK) $(BKGUI) # List of all objects in bk other than bk.o. Keep it sorted. # But put bkver.o/cmd.o first, they generate headers. OBJ = bkver.o cmd.o \ abort.o adler32.o alias.o admin.o annotate.o attributes.o \ bam.o bisect.o bkd.o bkd_bam.o bkd_cd.o \ bkd_changes.o bkd_client.o bkd_clone.o bkd_cmdtab.o \ bkd_findkey.o bkd_http.o \ bkd_id.o bkd_kill.o bkd_level.o bkd_misc.o bkd_nested.o \ bkd_partition.o bkd_pull.o bkd_push.o bkd_pwd.o \ bkd_r2c.o \ bkd_rclone.o bkd_rootkey.o bkd_status.o bkd_synckeys.o bkd_version.o \ bkverinfo.o \ cat.o cfile.o changes.o config.o \ check.o checksum.o clean.o cleanpath.o clone.o \ cmdlog.o \ collapse.o comment.o comments.o commit.o comps.o compress.o \ contrib/cat.o \ contrib/test.o \ converge.o \ cp.o \ crypto.o \ cset.o cset_inex.o csetprune.o csets.o cweave.o \ dataheap.o dbfile.o delta.o diff.o dspec.o \ export.o \ fast-import.o fast-export.o features.o findmerge.o \ find.o findcset.o fixtool.o fsl.o fslayer.o \ g2bk.o gca.o get.o gethelp.o \ gethost.o gettemp.o getuser.o gfiles.o glob.o \ gnupatch.o graft.o grep.o \ hash_nokey.o \ heapdump.o help.o here.o here_check.o hostme.o http.o \ idcache.o isascii.o info.o \ key2rev.o key2path.o kill.o kv.o \ libcommit.o libdiff.o libgraph.o librange.o \ libsfiles.o lines.o \ localtm.o lock.o locking.o \ mail.o merge.o mklock.o \ mailslot.o \ mtime.o mv.o names.o ndiff.o nested.o newroot.o \ opark.o \ parent.o park.o partition.o \ patch.o \ pending.o preference.o proj.o \ poly.o \ populate.o \ port/bkd_server.o \ port/check_rsh.o \ port/gethomedir.o \ port/gethost.o port/getinput.o \ port/getrealname.o port/getrusage.o port/globalroot.o port/gui.o \ port/hostColonPath.o port/http_proxy.o \ port/mail.o port/mnext.o port/networkfs.o \ port/notifier.o port/ns_sock_host2ip.o port/platforminit.o \ port/sccs_getuser.o port/sccs_lockfile.o \ port/startmenu.o \ port/svcinfo.o \ port/uninstall.o \ progress.o \ prs.o pull.o push.o pwd.o \ randombits.o randseed.o range.o rcheck.o rclone.o \ rcs2bk.o rcsparse.o \ receive.o redblack.o regex.o registry.o renumber.o \ remap.o remote.o \ repo.o repos.o repogca.o repostats.o repotype.o \ resolve.o resolve_binaries.o resolve_contents.o \ resolve_create.o resolve_filetypes.o \ resolve_flags.o resolve_generic.o resolve_modes.o \ resolve_renames.o resolve_tags.o restore.o review.o \ rm.o rmdel.o rmgone.o \ root.o rset.o sane.o scat.o sccs.o sccs2bk.o \ sccslog.o sccs_mv.o search.o sec2hms.o send.o sendbug.o \ set.o setup.o sfio.o shrink.o sinfo.o \ slib.o smerge.o sort.o startmenu.o \ stat.o stattest.o status.o stripdel.o synckeys.o \ tagmerge.o testcode.o tclsh.o takepatch.o \ testdates.o time.o timestamp.o touch.o trigger.o \ unbk.o undo.o undos.o unedit.o \ unique.o uninstall.o unlink.o unlock.o unpull.o unrm.o unwrap.o upgrade.o \ urlinfo.o \ utils.o uu.o what.o which.o \ xfile.o xflags.o \ zone.o SCRIPTS = bk.script import \ uuwrap unuuwrap gzip_uuwrap ungzip_uuwrap \ b64wrap unb64wrap gzip_b64wrap ungzip_b64wrap PSCR = t/doit t/guitest PROGS = libc/mtst$(EXE) LIBS = libc/libc.a DATA = bkmsg.txt bkhelp.txt version \ ../doc/bk_refcard.ps ../doc/bk_refcard.pdf ../RELEASE-NOTES.md \ dspec-changes dspec-changes-3.2 dspec-changes-4.0 dspec-changes-h \ dspec-changes-hv dspec-changes-json dspec-changes-json-v \ dspec-changes-vv dspec-log dspec-prs CONTRIB = gui/ide/emacs/vc-bk.el contrib/git2bk.l ALL = PCRE $(LIBS) $(BINS) $(SCRIPTS) $(PSCR) $(XTRA) \ $(PROGS) L-clean GUI L-doc $(DATA) CFLAGS = $(CC_DEBUG) export CFLAGS CPPFLAGS= -Ilibc $(TOMCRYPT_CPPFLAGS) $(TOMMATH_CPPFLAGS) \ $(PCRE_CPPFLAGS) $(LZ4_CPPFLAGS) $(ZLIB_CPPFLAGS) # Override this if you don't have it. RANLIB = ranlib # list of C sources in bk SRCS = bk.c $(OBJ:.o=.c) # list of headers in bk HDRS = bam.h bkd.h bk-features.h config.h configvars.def diff.h fsfuncs.h \ graph.h nested.h \ progress.h range.h rcs.h resolve.h sccs.h \ cmd.h poly.h proj.h redblack.h libc/system.h xfile.h # list of non-C sources in bk SCRSRCS = bk.sh import.sh kwextract.pl uuwrap.sh unuuwrap.sh \ port/unix_platform.sh port/win32_platform.sh \ gzip_uuwrap.sh ungzip_uuwrap.sh \ substvars.sh b64wrap.sh gzip_b64wrap.sh \ unb64wrap.sh ungzip_b64wrap.sh MISC = bkmsg.doc t/doit.sh default: $(MAKE) p SUBDIRS = libc $(shell ls -d tomcrypt tommath 2>/dev/null) all: $(ALL) prof: $(MAKE) CFLAGS="$G -pg -O2" LDFLAGS=-pg all gprof: $(MAKE) CFLAGS="$G -DPROFILE -pg -O2" LDFLAGS=-pg all ggprof: $(MAKE) CFLAGS="$G -DPROFILE -pg" LDFLAGS=-pg all # Debugging... d: $(MAKE) CFLAGS="$G -DDEBUG" all debug: $(MAKE) CFLAGS="$G -DDEBUG" all debug2: $(MAKE) CFLAGS="$G -DDEBUG2" all gWall Wall: $(MAKE) CFLAGS="$(CC_WALL)" all # production builds p: ## Build a production version of BitKeeper (no -g) $(MAKE) CFLAGS="$(CC_FAST) $(CF)" all trial: $(MAKE) TRIAL="3*WEEK" CFLAGS="$(CC_FAST) $(CF)" all trial3M: $(MAKE) TRIAL="3*MONTH" CFLAGS="$(CC_FAST) $(CF)" all g: ## Build a debug version of BitKeeper (-g) $(MAKE) CFLAGS="$(CC_DEBUG)" all gO: $(MAKE) CFLAGS="$(CC_FAST_DEBUG)" all gcov: $(MAKE) CFLAGS="$(CC_DEBUG) -fprofile-arcs -ftest-coverage" all clean: L-clean FORCE ## Remove object files and executables $(if $(Q),@echo Cleaning up,) $(Q)for sub in $(SUBDIRS) ../doc ../man gui utils win32 t t/win32; \ do $(MAKE) -C$$sub "CFLAGS=$(CFLAGS)" $@; \ done $(Q)$(RM) $(OBJ) bk.o $(BKG_O) $(BINS) $(SCRIPTS) \ $(PSRC) $(PROGS) $(Q)$(RM) tags TAGS tags.local cscope.out substvars a.out cmd.c cmd.h \ core *.bb *.bbg *.da *.gcov \ bk.ico \ bkmsg.txt bkhelp.txt bkver.c version \ t/doit t/guitest kw2val_lookup.c bkres.o svcmgr.exe \ conf.mk $(Q)$(RM) -r tmp ifeq "$(OSTYPE)" "msys" $(Q)$(RM) -rf gnu/bin gnu/doc gnu/etc gnu/share $(Q)$(RM) -f gnu/m.ico gnu/msys.bat gnu/msys.ico $(Q)-rmdir gnu/tmp $(Q)-rmdir gnu endif ifeq (true,$(INREPO)) ifneq (,$(INSTALLED_BK)) $(Q)EXTRALIST=`"$(INSTALLED_BK)" -Aax | \ grep -v '~$$\|conf-.*\.mk$$'` ; \ if [ "$$EXTRALIST" ]; then \ echo "Clean left behind the following files:" ; \ for file in $$EXTRALIST; do \ echo " $$file" ; \ done ; \ else \ echo Clean complete ; \ fi endif endif clobber: clean FORCE ## Same as 'clean' but also bk clean files -@$(BK) -A clean # XXX subdirs? (see tags) wc: $(HDRS) $(SRCS) $(SCRSRCS) $(MISC) wc -l $(SRCS) $(HDRS) $(SCRSRCS) $(MISC) get-e: FORCE -@$(BK) edit -qT `echo $(HDRS) $(SRCS) $(SCRSRCS) $(MISC) | fmt -1|sort -u` $(Q)$(MAKE) tags srcs: $(SRCS) $(HDRS) FORCE $(Q)for sub in $(SUBDIRS); do $(BK) -r$$sub co -q; done tags: $(patsubst %,%/tags.local, $(SUBDIRS)) tags.local @if [ -x $(BK) ]; \ then $(BK) get -Sq tags.skippats; \ $(BK) _sort -u $^ | grep -v -ftags.skippats > $@; \ else \ bk get -Sq tags.skippats; \ bk _sort -u $^ | grep -v -ftags.skippats > $@; \ fi @echo ctags completed tags.local: $(SRCS) $(HDRS) @ctags -f $@ --file-tags=yes --c-types=d+f+s+t $^ %/tags.local: FORCE $(Q)$(MAKE) -C $(dir $@) tags.local ssh sshtest: $(MAKE) realtest rsh rshtest: PREFER_RSH=YES $(MAKE) realtest test tests: DO_REMOTE=NO $(MAKE) -C t nonet nonet_test localtest: BK_NONET=YES PREFER_RSH=YES $(MAKE) realtest realtest: $(ALL) t/doit -cd gui/tcltk && $(MAKE) clobber -$(BK) get -qS t/setup t/win32/win32_common $(BK) -rt get -qTS 't.*' cd t && ./doit -f 5 guitest: $(ALL) t/doit -$(BK) get -qS t/SCCS/s.g.* t/setup t/win32/win32_common t/guitest.tcl cd t && ./doit -g -i t/doit: t/doit.sh substvars ./substvars t/doit.sh > t/doit chmod +x t/doit t/guitest: t/guitest.tcl cat < t/guitest.tcl > t/guitest .PHONY: FORCE FORCE: win32: FORCE cd win32 && $(MAKE) BINDIR=$(BINDIR) cd t/win32 && $(MAKE) # build libraries in sub directories %.a: FORCE $(Q)$(MAKE) -C $(dir $@) $(notdir $@) libc/mtst$(EXE): libc/libc.a FORCE $(Q)$(MAKE) -C libc mtst$(EXE) bkres.o: win32/data/bk.rc bk.ico windres -i win32/data/bk.rc -o bkres.o bk.ico: win32/data/bk.ico @cp -f win32/data/bk.ico . ifneq ($(TOMCRYPT_SYSTEM),1) # add dependency on building libraries first $(BK): $(TOMCRYPT_LDFLAGS) endif ifneq ($(TOMMATH_SYSTEM),1) # add dependency on building libraries first $(BK): $(TOMMATH_LDFLAGS) endif $(BK): $(LIBS) bk.o $(RESOURCE) $(OBJ) $(if $(Q),@echo LINKING $(BK),) $(Q)$(LD) $(LDFLAGS) -o $@ bk.o $(OBJ) $(RESOURCE) $(LIBS) \ $(TOMCRYPT_LDFLAGS) $(TOMMATH_LDFLAGS) \ $(PCRE_LDFLAGS) $(LZ4_LDFLAGS) $(ZLIB_LDFLAGS) $(XLIBS) # Windows only rule, BKGUI should be blank on other platforms $(BKGUI): bkg.o $(RESOURCE) $(if $(Q),@echo LINKING $(BKGUI),) $(Q)$(LD) $(LDFLAGS) -o $@ bkg.o $(RESOURCE) -Llibc -lc -mwindows $(XLIBS) bk.script: bk.sh port/$(SYS)_platform.sh cat port/$(SYS)_platform.sh bk.sh > bk.script chmod +x bk.script bkmsg.txt: bkmsg.doc cp -f $< $@ L-clean: FORCE @rm -f gui/share/doc/L/little.man ../man/man1/bk-little.1 @rm -f ../man/man2help/bk-little-1.fmt # has to run before bkhelp.txt but after GUI L-doc L-docs: GUI FORCE @test -f gui/share/doc/L/little.man || { \ echo Failed to build gui/share/doc/L/little.man; \ exit 1; \ } @if [ -s gui/share/doc/L/little.man ]; \ then cp gui/share/doc/L/little.man ../man/man1/bk-little.1; \ else cp ../man/man1/bk-little.1.pfmt ../man/man1/bk-little.1; \ fi; \ chmod +w ../man/man1/bk-little.1 bkhelp.txt: $(BK) version L-docs FORCE @rm -f ../man/man2help/bk-little.fmt @cd ../man/man2help && $(MAKE) BK=$(HERE)/bk$(EXE) helptxt @cp ../man/man2help/helptxt bkhelp.txt @rm -f ../man/man1/bk-little.1 html-docs: bkhelp.txt @cd ../man/man2html && $(MAKE) ../doc/bk_refcard.ps: $(BK) FORCE $(Q)echo building $@ $(Q)-$(BK) -r../doc co -qS $(Q)$(MAKE) -C ../doc BK=$(HERE)/bk$(EXE) all ../doc/bk_refcard.pdf: ../doc/bk_refcard.ps # This must be rebuilt every time because it includes the build time bkver.c: utils/bk_version FORCE $(if $(Q),@echo Building $@,) $(Q)echo "#include \"sccs.h\"" > bk.v $(Q)echo "char *bk_platform = \""`./utils/bk_version`"\";" >> bk.v $(Q)echo "int test_release = "$(TRIAL)";" >> bk.v $(Q)echo "time_t bk_build_timet = "`perl -e "print time"`";" >> bk.v $(Q)echo "char *bk_build_dir = \""`pwd`"\";" >> bk.v $(Q)mv -f bk.v bkver.c version: version.sh $(BK) utils/bk_version GUI FORCE bash version.sh > $@ %: %.sh $(if $(Q),@echo Building $@,) $(Q)$(RM) $@ $(Q)cp $< $@ $(Q)chmod +x $@ %: %.l $(if $(Q),@echo Not lexing $@,) import: import.sh port/$(SYS)_platform.sh cat port/$(SYS)_platform.sh import.sh > import.T chmod +x import.T mv -f import.T import # Quick and dirty target so we can make all the gui tools without the rest .PHONY: GUI GUI: PCRE $(BK) @$(MAKE) -Cgui BK=$(HERE)/bk$(EXE) gui install: installdir tmp/bitkeeper/bk _install -d -f $(DESTDIR)$(BINDIR) @echo BitKeeper is installed in $(BINDIR) @echo We suggest you run: @echo @echo sudo $(BINDIR)/bk links /usr/local/bin @echo @echo to create the bk symlink. installdir: utils/registry.tcl rm -rf $(IMGDIR) || exit 1 mkdir -p $(IMGDIR)/contrib mkdir -p $(IMGDIR)/lscripts -$(BK) -rwww get -S -cp -f -r www $(IMGDIR) -$(BK) get -S $(CONTRIB) tar cf - $(BINS) $(SCRIPTS) lscripts gui/bin gui/lib gui/images \ | (cd $(IMGDIR) && tar xf -) cp -f $(DATA) $(IMGDIR) cp -f $(CONTRIB) $(IMGDIR)/contrib (cd ../doc/nested && $(MAKE) install HTML=$(IMGDIR)/html) if [ $(SYS) = unix ]; \ then $(BK) get -S ../man/Makefile; \ cd ../man && $(MAKE) install BINDIR=$(IMGDIR) ;\ else \ (cd win32 && $(MAKE) BINDIR=$(IMGDIR) install); \ cp utils/registry.tcl $(IMGDIR)/gui/lib; \ fi cd $(IMGDIR); \ find . -type l | \ perl -ne 'chomp; $$a = readlink; print "$$a|$$_\n";'>symlinks; \ test -s symlinks || rm -f symlinks @true image: ## Build the installer (left in src/utils/bk-*) $(MAKE) p $(MAKE) _image _image: $(MAKE) installdir ${MAKE} -Cutils BINDIR=$(IMGDIR) "CC=$(CC)" "BK=$(HERE)/bk$(EXE)" "CFLAGS=$(CFLAGS)" image crankturn: crank.sh remote.sh ## Run a clean-build + regressions in cluster REPO=$(REPO) URL=$(URL) REMOTE=remote.sh LOG=$(LOG) bash crank.sh cranksave: crank.sh remote.sh ## Run a crankturn but save the built images REPO=$(REPO) URL=$(URL) REMOTE=remote.sh LOG=$(LOG) bash crank.sh save crankstatus: crank.sh remote.sh ## See how the crank is going REPO=$(REPO) URL=$(URL) REMOTE=remote.sh LOG=$(LOG) bash crank.sh status crankrelease nightly: $(BK) crank.sh remote.sh ## Do a BitKeeper release (or nightly build) @(TAG=$(shell $(BK) changes -r+ -d:TAG:) ; \ test x$$TAG = x && { \ echo Cannot crankrelease with a non-tagged tip ; \ exit 1 ; \ } ; \ case $@ in \ crankrelease ) \ TYPE=release; DIR=/home/bk/images/$$TAG; \ ;; \ nightly ) \ TYPE=nightly; DIR=/home/bk/images/nightly; \ HOSTS="$(NIGHTLY_HOSTS)" ; \ ;; \ esac ; \ test -d $$DIR || mkdir -p $$DIR ; \ REPO=$(REPO) URL=$(URL) HOSTS=$$HOSTS REMOTE=remote.sh \ LOG=$(LOG) bash crank.sh $$TYPE ; \ $(BK) -R get -qS ../RELEASE-NOTES.md ; \ cp ../RELEASE-NOTES.md $$DIR ; \ SAVED_WD=$(shell pwd) ; \ cd $$DIR && chmod +rx bk-* >/dev/null 2>&1 ; \ rm -f MD5SUMS ; \ md5sum bk-* >> MD5SUMS ; \ echo "Your images are in $$DIR" ; \ case $@ in \ crankrelease ) \ echo "Run './mkrelease $$TAG' to release this version of bk."; \ ;; \ nightly ) \ # cd $$SAVED_WD ; \ # ./mkupgrades --nightly $$TAG ; \ ;; \ esac) crankclean: crank.sh remote.sh REPO=$(REPO) URL=$(URL) REMOTE=remote.sh LOG=$(LOG) bash crank.sh clean # This target assumes a bk repository .PHONY: src-tar src-tar: $(BK) version ## build tar.gz image for the current tree ifeq (false,$(INREPO)) $(error This target only works in a BK source repository) else ./bk here add default TCLTK $(Q)-mkdir -p tmp/src $(Q)(DIR=bk-$(shell $(BK) version -s) ; \ TAR="$$DIR".tar.gz ; \ echo "Creating $$TAR in tmp/src..." ; \ cd tmp/src ; \ rm -rf "$$DIR" ; \ ../../bk export -tplain -kwr+ -sdefault -sTCLTK "$$DIR" ; \ cat ../../version > "$$DIR/src/bkvers.txt" ; \ tar -czf "$$TAR" "$$DIR" ; \ rm -rf "$$DIR" ; \ echo Done ; \ ) endif # only depend on conf.mk.local if it exists conf.mk: mkconf.sh $(wildcard conf.mk.local) sh mkconf.sh > $@ || { $(RM) $@; false; } %.o: %.c $(if $(Q),@echo CC $<,) $(Q)$(CC) $(CFLAGS) $(CPPFLAGS) -c $< -o $@ port/startmenu.o: port/startmenu.c $(HDRS) $(if $(Q),@echo CC $<,) $(Q)$(CC) $(CFLAGS) -fno-strict-aliasing $(CPPFLAGS) -c $< -o $@ depend: $(SRCS) $(CC) -MM -MG -D_DEPEND $(SRCS) > depends # for system.h we need to actually run libc's makefile because it includes # calculated header files libc/system.h: FORCE $(MAKE) -C libc system.h libc/libc.a: libc/system.h sccs.h: PCRE .PHONY: PCRE PCRE: ifneq ($(PCRE_SYSTEM),1) $(MAKE) -Cgui/tcltk pcre endif $(OBJ) bk.o: $(HDRS) cmd.c cmd.h: cmd.pl bk.sh $(filter bkd_%,$(SRCS)) $(if $(Q),@echo Building $@,) $(Q)perl cmd.pl || (rm -f cmd.c cmd.h; exit 1) # This parses slib.c and extracts the meta-data keywords expanded # by kw2val() and passes them to gperf to generate hash lookup code. slib.o: kw2val_lookup.c kw2val_lookup.c: slib.c kw2val.pl $(if $(Q),@echo Building $@,) $(Q)perl kw2val.pl slib.c || (rm -f kw2val_lookup.c; exit 1) check-syntax: $(CC) $(CFLAGS) $(CPPFLAGS) -c -S ${CHK_SOURCES} -o /dev/null # print a make variable 'make print-REPO' # http://www.cmcrossroads.com/article/printing-value-makefile-variable print-%: @echo $* = \"$($*)\" .PHONY: help help: @grep -E -h '^[-a-zA-Z_\ ]+:.*?## .*$$' $(MAKEFILE_LIST) | sort | awk 'BEGIN {FS = ":.*?## "}; {printf "\033[36m%-30s\033[0m %s\n", $$1, $$2}' @echo Suggested: make -j12 image

On Wed, Jun 19, 2024 at 08:44:14AM -0600, Warner Losh wrote: product architectures, Yeah, I lost that battle. I prefer, and carry around the sources to, a make from Unix. It's simple and does what I need. But my guys convinced me there was enough value in gmake that we used it. I tried to keep the craziness to a minimum. And I think I succeeded, I can fix bugs in that Makefile.

On Wed, Jun 19, 2024 at 08:44:14AM -0600, Warner Losh wrote: product architectures, Yeah, I lost that battle. I prefer, and carry around the sources to, a make from Unix. It's simple and does what I need. But my guys convinced me there was enough value in gmake that we used it. I tried to keep the craziness to a minimum. And I think I succeeded, I can fix bugs in that Makefile.

On Wed, Jun 19, 2024 at 06:28:46AM -0700, Larry McVoy wrote: Makefiles architectures, True, but it uses multiple GNU make features, include file inclusions, conditionals, pattern substitutions, etc. That probably worked for Bitkeeper because you controlled the build envirnment for the product, as you were primarily distributing binaries. From portability perspective for e2fsprogs, I wanted to make sure I could build it using the native build environment (e.g., suncc and later clang, not just gcc, and the default make distributed by Sun, AIX, Irix, HPUX, and later NetBSD/FreeBSD). I also wanted to support shared library support, and I didn't want to deal the horrific performance attributes of libtool and the inscrutibility of automake. Since my primary distribution channel was the source tarball (and later, a git checkout), and other high priority requirement for me is that I didn't want to require that people need to download some custom build infratrture. This rules out cmake, imake, gmake, and blaze (especially since blaze/bazel requires installing a Java <shudder runtime). And since I did want to use various advanced features (optionally, if they exist on the system) such as Poix Threads (which back then I couldn't take for granted as existing on all of the OS's that I supported) and Thread Local Storage, as opposed to just restricting myself to the BSD v4.4 feature subset, I needed to use autoconf anyway, and from a runtime perspective, it only requires m4 / awk / sed which is available everywhere. So I did everything using (only) autoconf, including building and using shared libraries,

On 20 Jun 2024, at 08:48, Kevin Bowling &lt;kevin.bowling(a)kev009.com&gt; wrote:  On Wed, Jun 19, 2024 at 11:59 PM Theodore Ts'o &lt;tytso(a)mit.edu&gt; wrote: <…> This is The Way if you really care about portability. Autoconf, once you get your head around what, why, and when it was created, makes for nice Makefiles and projects that are easy to include in the 100 Linux distributions with their own take on packaging the world. For those of a certain era, autoconf was both useful and relatively simple to use. In an era of many, divergent Unices, with different compilers, shared library implementations, and varying degrees of adherence to standards, it made using FOSS a matter of ‘./configure && make && make install’ which was massively easier than what had been required previously unless you happened to have exactly the same platform as the author. And to use it, you needed to understand shell, make, and m4, and learn a few dozen macros (at most). m4 was perhaps the least likely skill, but since it was used by sendmail(.mc), twmrc, X11 app defaults and various other stuff, most people already had a basic understanding of it. In my view the modern rejection of autoconf as “incomprehensible” mostly suggests that the speaker comes from a generation that never used the original Unix toolset. d

On 20 Jun 2024, at 16:37, Alexis &lt;flexibeast(a)gmail.com&gt; wrote: George Michaelson &lt;ggm(a)algebras.org&gt; writes: A point still being made: --https://rachelbythebay.com/w/2024/04/02/autoconf/

To build a set of objects you need to worry about at least the following: - build recipes for each of them (which may also depend on other things) - configuration parameters - dealing with differences on each platform - third party libraries & alternatives - toolchains (& may be cross-platform builds) - supporting/navigating different versions of the last 3 above You can't really precompute all this as there are far too many combinations and they keep changing.

Isn't that what thecautoconf cache is for?

At Fri, 21 Jun 2024 10:34:46 +1000, Alexis &lt;flexibeast(a)gmail.com&gt; wrote: Indeed there is. Nothing new about it either. It's been around for two decades or more.

It can be a bit fragile, especially in the "gradually accumulates" way of using it (which is why pkgsrc avoids that), but usually the fault lies squarely on the shoulders of developers who either don't read the Autoconf documentation, or think that somehow they're smarter than Autoconf and the many decades of lore it encodes.

"Greg A. Woods" &lt;woods(a)robohack.ca&gt; writes: TIL - thank you! i've never seen this mentioned before. (Perhaps because i only use autoconf as an end-user, rather than as a dev.)

specify that `-C` / `--config-cache` be passed to configure by default site-wide. So i might do so on my Gentoo system - given most things on that system are locally compiled, it might be an interesting stress-test data-point regarding configuration caching. Alexis.

On Jun 20, 2024, at 4:35 PM, Alexis &lt;flexibeast(a)gmail.com&gt; wrote: If i compile something on one of my OpenBSD boxen in the morning, and then compile some other thing in the afternoon, without an OS upgrade in-between, autoconf isn't going to find that libc.so has changed in-between. If i did the same thing on my Gentoo box, it's theoretically possible that e.g. i've moved from glibc to musl in-between, but in that case, precomputation could be done in postinst (i.e. as part of the post-installation-of-musl process).

Bakul Shah bakul(a)iitbombay.org writes: The basic things are, in fact, a significant part of what autoconf is being used to check for. "Does this platform provide this function?" ... Alexis.

Bakul Shah via TUHS &lt;tuhs(a)tuhs.org&gt; writes: Both the blog author (who is a long-time sysadmin with many 'war stories') and myself understand all that. i believe the idea is not for precomputing to be done by _builds_, but to be done on and for a given machine and its configuration, independent of any specific piece of software, which is then _queried_ by builds. That precomputation would only need to be re-run when one of the things under its purview changes. If i compile something on one of my OpenBSD boxen in the morning, and then compile some other thing in the afternoon, without an OS upgrade in-between, autoconf isn't going to find that libc.so has changed in-between. If i did the same thing on my Gentoo box, it's theoretically possible that e.g. i've moved from glibc to musl in-between, but in that case, precomputation could be done in postinst (i.e. as part of the post-installation-of-musl process). Alexis.

So, to what extent is the complexity of autoconf _needed_ nowadays?

i believe the idea is not for precomputing to be done by _builds_, but to be done on and for a given machine and its configuration, independent of any specific piece of software, which is then _queried_ by builds. That precomputation would only need to be re-run when one of the things under its purview changes.

If i compile something on one of my OpenBSD boxen in the morning, and then compile some other thing in the afternoon, without an OS upgrade in-between, autoconf isn't going to find that libc.so has changed in-between.

Chet Ramey via TUHS &lt;tuhs(a)tuhs.org&gt; writes: Sorry, i'm not sure i understand your question, particularly given that i was writing about the situation where a fundamental part of the build environment _hasn't_ changed .... Could you please elaborate or rephrase?

On 23 Jun 2024, at 04:16, Luther Johnson &lt;luther.johnson(a)makerlisp.com&gt; wrote: If I could say something a little more meta, and echoing an earlier comment - autotools, configure, etc, don't do the port for you - it's up to the author to decide and test what OS features are required, and if something hasn't been too implicitly assumed, if a "needs this" hasn't been left out, then the "configure && make" process will give you the right build for a system that is indeed, already supported. If it doesn't build, we can interpret that as "not supported", or that the author did not sufficiently adjust input to the build process, or test similar-enough configurations, to get the right build for that system.

As an example, mentioned up-thread, building on Ultrix in 2024: you need to test and work around a bunch of things that have been fixed on anything updated since the mid-90’s to get a clean build on Ultrix, SunOS-4.x, etc. Your average Linux or macOS user sees this as pointless time wasting.

There’s no right answer here: someone is always annoyed at you.

On 6/22/24 2:15 PM, Luther Johnson wrote: A third possibility is that the author or authors decided not to test for and support a set of (in this case) older systems. Not a lack of imagination, but a development priority decision.

On Sun, Jun 23, 2024 at 04:15:40PM -0400, Stuff Received wrote: I get irked because Posix compliance applies to OS's (a specific binary release of the kernel plus userspace runtime environment), and not to applications. Also, compliance implies that it has passed a specific test process, after paying $$$$ to a Posix Test Compliance Lab, and said compliance certificate gets revoked the moment you fix a security bug, until you go and you pay additional $$$ to the Posix compliance lab. Basically, it's racket that generally only companies who need to sell into the US or European government market were willing to play. (e.g., at one point there were Red Hat and SuSE distributions which were POSIX certified, but Fedora or Debian never were.) A project or vendor could claim that there product was a "strictly conforming POSIX application[1], but that's hard to actually prove (which is why there is no compliance testing for it), since not only do you have to limit yourself to only those interface guaranted to be present by POSIX, but you must also not depend on any behavior which specified to be "implementation defined" (and very often many traditional Unix behaviors are technically "implementation defined", so that VMS and Windows could claim to be be "POSIX compliant implementation".) So a strictly POSIX conforming application was likely only relevant for very simple "toy" applications that didn't need to do anything fancy, like say, networking.

(Berkeley sockets couldn't be required because AT&T Streams. Oh, joy.) [1] https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap02.html#ta… Can you tell I'm a bit jaded and cynical about the whole Posix compliance/conformance thing? :-) Cheers, - Ted

My opinion is that the authors simply did not have access to other systems or were not interested.  Sometimes, one finds a disclaimer to that effect. I understand that but I am irked when they claim POSIX compliance.

On Mon, 17 Jun 2024, Stuff Received wrote: Which is why I'm glad Debian's /bin/sh is dash (fork of ash) instead.

On 15 Jun 2024, at 00:18, Grant Taylor via TUHS &lt;tuhs(a)tuhs.org&gt; wrote: It's my understanding that systemd as a service lifecycle manager is starting to take on some aspects of what cluster service managers used to do.

I think there's a parallel from the Unix/Linux systems that we think of as more Unix-like, to the cars and airplanes and other machines of that and earlier eras. It used to be that part of the design of a system, alongside its operation, was the idea of normal, regular maintenance. The system could be pretty simple, but there was some maintenance and wearable parts replacement required. It was expected that there was an administrator or mechanic checking in once in a while to keep things tuned and in "good repair". This worked well, as long as people accepted this responsibility as part of the deal. Now it seems like people want everything done for them automatically, and not to have to know anything about the systems they are using. They want the systems to be smarter so they don't have to know as much. It's sort of like when the private airplane industry tried to engineer any skill required on the part of the pilot, out of the airplane. The results were not good. Planes became more complex, with more points of failure, and pilots did not know how to react to unexpected situations. I see this happening with our computer systems, and the people using them now, too. Of course there's a reasonable middle ground, but I think we've gone a little too far making things "easy", and in fact it's not easier at all, we're just fiddling in a different way, often through random trial and error, it all seems horribly indirect, opaque, and irrational, to support some programmer's idea somewhere, of some perfect abstraction. For example: CMake vs. just learning how to write makefiles properly. You fiddle with CMake and you never really know why it does what it does, especially from one version to the next, "but you don't have to write makefiles".

I think it goes beyond this, and that systemd is just a convenient focus point for folks to push back against a wider set of changes.

-- https://skarnet.org/lists/supervision/2586.html

On Thu, Jun 13, 2024, at 14:39, segaloco via TUHS wrote: [...]

I'm interested in hearing about other options in this space, too.

On Thu, Jun 13, 2024, 3:38???PM Alan D. Salewski &lt;ads(a)salewski.email&gt; wrote: https://nosysyemd.org

"Alan D. Salewski" &lt;ads(a)salewski.email&gt; writes: i'm currently running Gentoo+OpenRC as my daily driver, with OpenRC an 'official' Gentoo option. https://www.gentoo.org/ Previously i was running Void+s6/66, after having been running Void+runit, with runit being Void's default system (at least at the time). https://voidlinux.org/ Artix is an Arch-based non-systemd distro, with support for OpenRC, runit, s6 and dinit. https://artixlinux.org/ Obarun is an Arch-based distro using 66, which is roughly a 'wrapper' for s6, providing declarative syntax for service definition. https://wiki.obarun.org/ Not a distro, but the s6-overlay project allows using s6 as PID 1 in Docker containers: https://github.com/just-containers/s6-overlay The developer of nosh has a page outlining the know problems with Sys V rc: https://jdebp.uk/FGA/system-5-rc-problems.html The developer of dinit has written a nice comparison of various non-systemd systems providing init / service supervision / service management: https://github.com/davmac314/dinit/blob/master/doc/COMPARISON The developer of s6 has pages: * explaining his perspective on various non-systemd systems: https://skarnet.org/software/s6/why.html * providing a general overview of s6 itself: https://skarnet.org/software/s6/overview.html * discussing s6's approach to 'socket activation', which uses file descriptors: https://skarnet.org/software/s6/socket-activation.html (s6 is the system i'm most familiar with in this space, not least because i'm the porter and maintainer of mdoc(7) versions of the documentation for various parts of the s6/skaware ecosystem.) Alexis.

This is all well and good but what I, and I suspect other boomers like me, are looking for, is something like Ubuntu without systemd. I'm a xubuntu guy (Ubuntu with a lighter weight desktop), but whatever. Ubuntu is fine, everything works there. So is there an "Everything just works" distro without systemd? A guy can hope but I suspect not.

I'm not trying to be a pain in the ass but I'm 62, I prefer to spend my effort on fishing on the ocean, I'm not some young guy that wants to put in a ton of hours on my Linux install

Mm, well, i guess that depends on what one's "everything" is. i used Ubuntu years ago - having moved from Mandriva - and was pleased by how everything "just worked". But over time i started experiencing various issues where things _didn't_ just work (i can't remember what now; i think printing might have been one thing), which became increasingly frustrating. So i moved to Debian, and had a much more "just works" experience. But then Debian moved to systemd, and i started getting frustrated again in various ways, and so i moved to Void.

This is all well and good but what I, and I suspect other boomers like me, are looking for, is something like Ubuntu without systemd. I'm a xubuntu guy (Ubuntu with a lighter weight desktop), but whatever. Ubuntu is fine, everything works there. So is there an "Everything just works" distro without systemd? A guy can hope but I suspect not. I'm not trying to be a pain in the ass but I'm 62, I prefer to spend my effort on fishing on the ocean, I'm not some young guy that wants to put in a ton of hours on my Linux install, I like Linux because it is Unix and it is trivial to install. Windows? Hours and hours of finding drivers after you find some USB network connector that Windows knows? No thanks. *BSD - have you installed one of those? It's a trip back to the 1980s, those installers are fine for BSD developers but just suck compared to Linux. Mainstream Linux just works.

For daily tasks I am using Macbook which also just works and have a terminal, so I can run my stuff from there. I can control my k8s clusters from the terminal. I am still mostly CLI oriented. Command line will always remain the most elegant and beautiful interface to speak with machines.

Binary logs, ’nuff said.

Good sysadmins live & die by grep and being able to visually detect departures from the norm by just looking at the “shape” of logs scrolling down a screen (before), terminal window now.

someone has dreamed up; I certainly don't see anything like that in the actual release announcement at <https://github.com/systemd/systemd/releases/tag/v256>. Also using multiple different search engines to try to find it only brought up the _The Register_ article and a handful of places regurgitating that quote as a real representation of a statement from the systemd maintainers. I don't see anything resembling it anywhere on either systemd.io or github.com. Until I see someone posting a link to something like that quote posted by a systemd maintainer in representation of _any_ systemd release, let alone v256, I'm going to treat that one as hearsay at best, and actively malicious at worst.

journalctl -f -u 'smtpd' or whatever else might map to the SMTP server software you're running. (Sure, it gets slightly more complicated if you don't know what SMTP server software is in use, but in that case I think a case can be made for why do you even care about its logs?)

Dave Horsfall &lt;dave(a)horsfall.org&gt; writes: It's systemd's program for accessing the binary logs it generates. So, yes, it's Penguin, in the sense that systemd is explicitly not supported on anything other than Linux.

Except you now have to do the additional step of extracting the data from the binary logs and _then_ apply the regex filter you were going to use in the first place, which makes the logs less accessible. All of my systemd running machines still get rsyslog plugged into it so it can deliver the logs to my central log host (which then dumps them into PostgreSQL) - and to enable a quick rummage in the local logs via less & grep.

On Mon, Jun 24, 2024 at 9:51 AM Theodore Ts'o &lt;tytso(a)mit.edu&gt; wrote: I must concur here. To bring this back to history, I think it's useful to consider the context in which, "use text, as it's a universal interchange format" arose. We _are_ talking about the 1970s here, where there was a lot more variation between computers than nowadays; back in that era, you still had a lot of word-oriented machines with non-power-of-2 word sizes, one's complement machines, and the world had not yet coalesced around the 8-bit byte (much of networking is _still_ defined in terms of "octets" because of this). In that era, yeah, it was just easier to move text between programs: transporting a program from a 16-bit machine to a 32-bit machine didn't mean changing parsing routines, for example. Contrast this to today, where things are much more homogenized, even between different ISAs. Most ISAs are little endian, and for general purpose machines 8 bit bytes, power-of-two integer widths, and 2's complement are pretty much universal (I'm aware that there are some embedded and special purpose processors --- like some types of DSPs --- for which this is not true. But I'm not trying to run Unix on those). Furthermore, we have robust serialization formats that allow us to move binary data between dissimilar machines in a well-defined manner; things like XDR -- dating back almost 40 years now -- paved the way for Protobuf and all the rest of them. In this environment, the argument for "text first!" isn't as strong as it was in the 70s. Something that I think also gets lost here is that we also have well-defined, text-based serialization formats for structured data. Things like sexprs, JSON, have all been employed to good effect here. You can have your textual cake and eat your structured data, too! I think what irks people more is that the traditional, line-oriented tools we all know and love are no longer prioritized. But to me that's an invitation to ask "why?" The default assumption seems to be that the people who don't are just ignorant, or worse, stupid. But could it be that they have actual, real-world problems that are not well served by those tools? So it is with systemd. I don't like it, and the recent, "deletes your homedir lol you're holding it wrong lmao" thing solidifies that opinion, but in some ways it's actually _more_ Unix-y than some of the alternatives. Take smf, where nothing screams "UNIX!!!" at me more than XML-based config files consumed by giant libraries. Systemd, at least, is broken into a bunch of little programs that each do one thing (sorta...) well, and it uses somewhat-readable text-based configuration files and symlinks. Indeed, we look at what we consider "real Unix" with some very rosy glasses. Perhaps that's why we overlook un-Unix-like functionality like Solaris's "profile" facilities, where the kernel does an upcall to a userspace daemon to determine what privileges a program should have? Or how about the IP management daemon, in.ndpd, or the rest of the libipadm.so stuff? Unix hasn't been Unix for a very long time now.

- Dan C.