Path: csiph.com!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: New and improved version of cdecl Date: Sat, 25 Oct 2025 15:14:38 -0700 Organization: None to speak of Lines: 82 Message-ID: <87a51e1ve9.fsf@example.invalid> References: <87bjlyobts.fsf@example.invalid> <10dbvqs$12d0f$1@dont-email.me> <10dd0fj$1jbcv$1@dont-email.me> <87jz0l2pal.fsf@example.invalid> <10dei5s$28h93$1@dont-email.me> <8734792h4y.fsf@example.invalid> <10dfusd$2k0q4$1@dont-email.me> <10dgdc7$2of3m$1@dont-email.me> <10dghp5$2q30g$1@dont-email.me> <10dias4$37h93$1@dont-email.me> <10dirfi$3ek8r$1@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Date: Sat, 25 Oct 2025 22:14:39 +0000 (UTC) Injection-Info: dont-email.me; posting-host="fad009138e513e5a0bdb3c4e9368036f"; logging-data="3812557"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/lxM+rSdXhEtqX1YDhICMj" User-Agent: Gnus/5.13 (Gnus v5.13) Cancel-Lock: sha1:qLuCMr7TPEsC8nYKOTz07ybP4WI= sha1:yc9INWSBEM+aWW8S6DNHcZDrUV0= Xref: csiph.com comp.lang.c:394731 bart writes: > On 25/10/2025 12:04, David Brown wrote: >> On 24/10/2025 20:50, bart wrote: >>> I was talking about all the stuff scrolling endlessly up to the >>> screen for a minute and a half while running the configure script >>> and then compiling the modules. >>> >> You are getting worked up about some text output that scrolled >> "endlessly" for a minute and a half?  (Do you spot the exaggeration >> here?)  Of course it is less of an issue for me - "./configure" took >> a mere 10 seconds on my ten year old machine.  But even at a minute >> and a half, it's just a task that the computer runs, once, and it is >> done without effort.  Try relaxing a little more, and perhaps use >> that minute and a half to stretch your legs or drink some coffee, >> rather than to build up a pointless fury. > > The point about the minute and a half is that a fast compiler even on > my machine could translate tens of millions of lines of source code in > that time. If the app was actually that size (say, a web browser) then > fine. > > But the C source is only 0.07Mloc. So what TF is going on? > > It appears that this is one of those apps that is superfically written > in 'C' but it actually relies on a plethora of other languages, files, > tools and myriad kinds of options. You can't just go into ./src and do > 'gcc *.c'. > > Even the makefile has to first be generated. There are files with .in, > .am and .m4 extensions. The eventual 'makefile' has 2000 lines of > gobbledygook, to build 49 C modules. (My projects are also around 40 > modules; the build info comprises, funnily enough, some 40 lines.) > > So this is a complicated build process! Unfortunately it is typical of > such products originating from Unix-Linux (you really want one term > that you can use for both). > > This is not specific to CDECL; it's nearly everything that comes of > Unix-Linux. But this came up and I had a look. Yes, the build process is *internally* complicated. When I type the three or so commands needed to build and install the tool from source, it uses a lot of non-C input files, and generates some large intermediate files. None of that bothers me when I install it on a Unix-like system. There's no particular reason for me to care. It obviously bothers you, particularly if you want to install it on pure Windows. So what are you going to do about it? So far, you've been complaining *for years* to a group of people who are not in a position to do anything about it. I am not a GNU autotools maintainer, and as far as I know nobody else here is either. Maybe GNU autotools could be modernized, not bothering to check for language and library features that are now universally supported. Maybe it could be updated to work better on pure Windows, without Cygwin or WSL or MSYS. Maybe that's something useful you could work on. That kind of work could make hundreds or thousands of existing software tools easier to build and install. Or if you only want to talk about it, maybe it would be more productive to do so on one of the GNU mailing lists. (If you do, be aware that a lot of the people you'll be talking to don't care about MS Windows.) > But let me ask then about this particularly app (an interactive > text-based program where performance is irrelevant; it could have been > written in Python): do you think it would have been possible to > distribute this as a set of 100% *standard* C source files, with the > only dependency being *any* C compiler? I haven't studied the source. Maybe you're right. Maybe *you* could work on it. If you can adapt the existing cdecl program into, say, a single portable C source file, so it can easily be built either on Unix-like systems or on Windows, that could actually be useful. It's GPL licensed, so you can create your own forked version, just as the current maintainer has. (I would ask that you at least retain the option to use GNU readline, so there would have to be *some* configuration.) -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com void Void(void) { Void(); } /* The recursive call of the void */