From: Keith.S.Thompson+u@gmail.com   
      
   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 */   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)