[TUHS] Re: Building programs (Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register

[segaloco via TUHS <tuhs@tuhs.org>]

On Saturday, June 22nd, 2024 at 2:16 PM, David Arnold <davida@pobox.com> wrote:

> > On 23 Jun 2024, at 04:16, Luther Johnson luther.johnson@makerlisp.com 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.
> 
> 
> The author thus ends up searching for a sweet spot: test too many things, and people complain that you’re wasting time checking something that is always true; test too few, and it will break on relatively common platforms.
> 
> 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.
> 
> 
> 
> 
> d

Well and part of that is indeed being intentional about platform support, fancy toolkit or not.  If you're specifically intending to support just a particular vendor's platform, you make programming choices, not build machinery choices, towards that end.  Similarly, if you truly expect something you write to work everywhere with minimal modification, no amount of build machinery is a substitute for pulling up and adhering as closely to POSIX as possible, same with non-UNIX platforms and being intentional about ANSI C.

Now, if you're trying to use things these least common denominators don't include, like for instance ANSI C+thread support, build machinery still isn't going to be what makes your program work, you have to write or otherwise incorporate an abstraction layer over the available system services, be it pthreads, Win32 threads, etc.

That all said, one excellent point I must agree with up thread is that a build system will be used by a small handful of devs but then countless consumers who aren't experts in programming and that expect things to "just work". We as programmers may be fine with an "alias cc=<insert cross-compiler here>" to avoid some lengthy cross-compiler detection mechanism in our own development process, but tell every consumer they have to set a bunch of environment variables and/or aliases to get a makefile to work and they'll throw their hands up and look for something with a configure script *even if* the former really is an easier and more dependable way to get exactly what you want.

I say this because the former is how I've handled personal projects for a bit now, if I do need any environmental difference from the flat makefile in my project, I setup that environment just-in-time by hand, which usually just amounts to aliasing a command or too, maybe adding to LD_LIBRARY_PATH, that sort of thing, or if it's frequent enough, just do this with a teeny tiny script.  I like the control and terseness of the setup, but throw that at someone who is used to using a package manager or at most using a configure script or CMake, and yeah, they'd probably balk at the lack of "sophistication" in your distributable.

Looking at it as an accessibility matter rather than a developmental necessity certainly gives me different feelings about all this stuff.  I may not need it and indeed would likely be mildly inconvenienced in some situations, but for someone else, it's a crucial piece of their experience.  These words may ring true about the original subject of systemd as well...

- Matt G.