On 3/18/25 09:03, Steffen Nurpmeso wrote: Yes, we still maintain Imake upstream at X.Org, but every new release for years has had notes like: The X Window System used imake extensively up through the X11R6.9 release, for both full builds within the source tree and external software. X moved off of imake for its build system in 2005 for X11R7.0 and later releases, but still provides imake for building existing external software programs that have not yet converted, though we are not actively maintaining it for new OS or platform releases. Anyone shipping software still using imake to build should be working on moving to something that is still adding support for new platforms and runtimes. as seen in https://lists.freedesktop.org/pipermail/xorg/2024-January/061524.html We don't even use Imake to build itself - since 2005 it has been built with autoconf & automake, and this year I merged the changes to let it build with meson instead: https://gitlab.freedesktop.org/xorg/util/imake/-/merge_requests/13 But I don't have a copy of the paper referred to in the first email in this thread, and both the sites we link to for Imake information from the Imake README seem to have died now: https://www.snake.net/software/imake-stuff/ https://www.kitebird.com/imake-book/ -- -Alan Coopersmith- alan.coopersmith(a)oracle.com Oracle Solaris Engineering - https://blogs.oracle.com/solaris

I make relies on having an independently callable C preprocessor that they make assumptions what the output from it look (which is not anything laid down by a standard or the like). We used to use Imake extensively to build our code base, and tehre were platforms I had to bring along my own CPP because the one for the compiler didn’t work for the purpose (mostly issues with space and tab substitutions). We eventually switched to CMAKE.

At 2025-03-18T12:03:48-0700, Greg A. Woods wrote: I believe the usual rejoinder here is "worse is better". My experiences with CMake are not happy ones. Regards, Branden

I didn’t much care for it myself (and fortunately, it wasn’t my job to maintain the build production). It at least gave us common tools for Windoze and UNIX. ------ Original Message ------ From "G. Branden Robinson" <g.branden.robinson(a)gmail.com> To tuhs(a)tuhs.org Date 3/18/2025 3:09:09 PM Subject [TUHS] Re: "Imake: an obsolete build tool" -- anybody got this?

Alan Coopersmith via TUHS wrote in <95e2b2eb-4830-4fe1-9492-65bc53d3f297(a)oracle.com>: |On 3/18/25 09:03, Steffen Nurpmeso wrote: |> ron minnich wrote in |> <CAP6exY+4hfjs0rfMA-pSRYj0Qi5SiXM+qqyCyJdErws9HYHpwQ(a)mail.gmail.com>: |> |>|I know it's out there, I just can't find it. | |> name=xorg-imake |> version=1.0.10 |> release=1 |> source=(https://www.x.org/releases/individual/util/imake-$version.tar.\ |> xz) | |Yes, we still maintain Imake upstream at X.Org, but every new release \ |for years |has had notes like: ... |But I don't have a copy of the paper referred to in the first email in this |thread, and both the sites we link to for Imake information from the Imake |README seem to have died now: | | https://www.snake.net/software/imake-stuff/ | https://www.kitebird.com/imake-book/ yes, the timeouts i also had from Germany. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)

On Tue, Mar 18, 2025 at 8:49 PM ron minnich <rminnich(a)gmail.com> wrote: Which paper has this in its bibliography? -- Daria Phoebe Brashear AuriStor, Inc dariaphoebe.com

Actually, here ya go: https://archive.org/details/login_jan94 On Tue, Mar 18, 2025 at 12:44 PM Daria Phoebe Brashear <shadow(a)gmail.com> wrote: -- Daria Phoebe Brashear AuriStor, Inc dariaphoebe.com

If you mean https://www.nic.funet.fi/pub/unix/security/docs/usenix/usenix/winter88/x-he… I ran ps2pdf on it (via homebrew) and it opened right up. On Tue, Mar 18, 2025 at 1:05 PM ron minnich <rminnich(a)gmail.com> wrote: -- Daria Phoebe Brashear AuriStor, Inc dariaphoebe.com

On Tue, Mar 18, 2025 at 1:23 PM ron minnich <rminnich(a)gmail.com> wrote: Yep - so does Acrobat if you have it. As Henry once so wisely observed: "*4.2BSD is just like UNIX, only different.*" DEC lived, and, I guess, eventually died, by "The Promise" - that old things kept working on newer releases. Be it VMS, Ultrix, Tru64 or whatever. Maybe not easily, maybe not fast, But they worked. If you were "inside" it, was very difficult to remove an old feature. It may also be that DEC and the like cared about the ISVs and the promise was for more that the end user. Modern systems (to be fair, even penguins) don't seem to care as much about that idea. The license to "improve" something or "deprecate" old behavior is based on a Greek hubris that was taught to many over the years. Apple and Microsoft often seem to have always had a few extra helpings. It seems silly to me, too. BTW: ps2pdf is using ghostscript under the covers, so you should have been able to call it directly. In "brew" pstools kits which ps2df is part, requires it and thus ensures it is installed. ᐧ

On 3/18/25 1:04 PM, ron minnich wrote: I have a pdf of that paper. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet(a)case.edu http://tiswww.cwru.edu/~chet/

On 3/18/25 4:05 PM, Dave Horsfall wrote: 14. Rosenthal, D., “A Simple X11 Client Program,” USENIX Winter Conference Proceedings, pp. 229-242, Dallas, 1988 (the subtitle is "How hard can it really be to write "Hello, World"?"). https://archive.org/details/1988-proceedings-winter-tech-dallas If you agree that's the one we're talking about, I'll send it to Warren. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet(a)case.edu http://tiswww.cwru.edu/~chet/

On Tuesday, March 18th, 2025 at 1:40 PM, Chet Ramey via TUHS &lt;tuhs(a)tuhs.org&gt; wrote: One thing this article doesn't address in my mind is what precisely is a given user trying to achieve with a "Hello, World" application. On one hand is the "Does my environment function" role in which I think their application may have been a bit heavy handed for. In my mind this would amount to: - Retrieve the display - Create a window in it - Map the window - Loop to allow it to display - Unmap the window - Cleanup With looping to display in particular being based on some non-specific termination that could be as simple as a timer/countdown. After all, all I want to know is can I build and run something targeting Xlib, all the rest is then can I use specific feature of Xlib <xyz>, for instance, displaying text. Even polling for keyboard events to perhaps catch an Esc press isn't really relevant to the question of will a window map, display in the event loop, then unmap when the event loop is terminated. On the other hand, a "Hello, World" is often used as the least common denominator application that allows text-based feedback to a user, thereby facilitating using that display mechanism for feedback throughout ongoing development. For instance, my minimal "Hello, World" for microcontrollers tends to be just verifying I can drop a single character in the transmitter of a UART and get that character back on the connected tty. Once I have such a putc, I have my first debug mechanism. Not intended as critique either, just some philosophical questions that arose thinking about "what do I want to achieve" regarding a classic "Hello, World" program. They do touch on this in the article too but I think there is a tad bit lost comparing the Xlib implementation to the use of printf. To quote: But some of the efficacy of this mention is lost without the comparison being between "Hello, World" using nothing but syscalls. For instance all the matters of getting the graphics context correct, color space, resizing, etc. sound like concerns comparable to those far removed from a printf() user by the tty driver, things like ioctl(), etc. Nice read though. Obviously they touched on a philosophical question that can continue to be kicked around in all sorts of ways. - Matt G.