From: bc@freeuk.com   
      
   On 24/10/2025 21:20, Keith Thompson wrote:   
   > bart  writes:   
   >> On 24/10/2025 18:35, David Brown wrote:   
   >>> On 24/10/2025 15:27, bart wrote:   
   >>>> On 24/10/2025 03:00, Keith Thompson wrote:   
   >>>>> bart  writes:   
   >>>>>> On 24/10/2025 00:04, Keith Thompson wrote:   
   >>>>>>> bart  writes:   
   >>>>> [...]   
   >>>>>   
   >>>>> I note that you've ignored the vast majority of my previous article.   
   >>>>   
   >>>> I've noted it, but chose not to reply. You have a point of view and   
   >>>> attitude which I don't share.   
   >>>>   
   >>>> Mainly that you don't care how complicated a program for even a   
   >>>> simple task is, and how laborious and OS-dependent its build   
   >>>> process is, so long as it (eventually) works.   
   >>>>   
   >>>> That it favours your own OS, leaving users of other to have to jump   
   >>>> through extra hoops, doesn't appear to bother you.   
   >>>>   
   >>> Why would someone care what how someone else writes their code, or   
   >>> what it does, or what systems it runs on?  They guy who wrote cdecl   
   >>> gets to choose exactly how he wants to write it, and what systems it   
   >>> supports. We others get it for free - we can use it if we like and   
   >>> it if it suits our needs.  But neither Keith nor anyone else paid   
   >>> that guy to do the work, or contributed anything to the task, and we   
   >>> have no right to judge what he choose to do, or how he choose to do   
   >>> it.   
   >>   
   >> This a curious argument: it's free software so you don't care in the   
   >> slightest how efficient it is or how user-friendly it might be to   
   >> build?   
      
   'Efficiency' is about lots of different aspects. If you use a metric   
   which compares the scale of the actual task (compile a small,   
   interactive console-based program into an executable) with what actually   
   needs to be done here, it is wildly out of proportion.   
      
   As one consequence of that, it is impossible to build on pure Windows.   
      
   > Its efficiency is not a great concern.  I've seen no perceptible delay   
   > between issuing a command to cdecl and seeing the result.  No, I don't   
   > much care what it does behind the scenes.  If I did care, I might look   
   > through the sources and try to think of ways to improve it.  But the   
   > effort to do so would vastly exceed any time I might save running it.   
   >   
   > The build and installation process for cdecl is very user-friendly.   
      
   Unless you're on Windows, because it is designed for Linux and Unix   
   systems ONLY. Even on the latter, nobody messes with it because it is so   
   complicated. Just cross your fingers and hope nothing goes wrong   
   otherwise you're f***ed.   
      
      
   >  It   
   > matches the process for thousands of other software packages that are   
   > distributed in source.  I can see that the process might be confusing if   
   > you're not accustomed to it.  If you *asked* rather than just   
   > complaining, you might learn something.   
   >   
   > The stripped executable occupies about 0.000008% of my hard drive.   
   >   
   >> This is a program that reads lines of text from the terminal and   
   >> translates them into another line of text. THAT needs thirty thousand   
   >> lines of configure script?! And that's even before you start compiling   
   >> the program itself.   
   >   
   > The configure script is automatically generated from "configure.ac",   
   > which is 343 lines, 241 lines if comments and blank lines are   
   > deleted.  I've never written a configure.ac file myself, but most   
   > of it looks like boilerplate.  It would probably be fairly easy   
   > (with some experience) to create one by modifying an existing one   
   > from another project.   
      
   Or you could scrap the configure script completely. How about that?   
      
   >> 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.   
   >   
   > Why is that a problem?  If you like, you can redirect the output of   
   > "./configure" and "make" to a file, and take a look at the output later   
   > if you need to (you probably won't).   
      
   It's a problem because I can see all the stupid crap it wastes time   
   doing. Does it really need to test whether 'stdio.h' is available, and   
   what happens if it isn't? Wouldn't you find out as soon as you try to   
   compile anything?   
      
   (I remember trying to build A68G, an interpreter, on Windows, and the   
   'configure' step was a major obstacle. But I was willing to isolate the   
   12 C source files involved, then it was built in one second.   
      
   I did of course try building it in Linux too, and it took about 5   
   minutes that I recall, using a spinnning hard drive, mostly spent   
   running through that configure script.   
      
   Utterly pointless. And if I'd wanted to build another application on the   
   same machine, it would have to do all the tests again!   
      
   What on earth could have changed? If you say that the environment   
   /could/ change between those two builds, then equally it could have   
   changed during the minute or so between the configure tests, and   
   starting to compile code.)   
      
      
   >   
   > [...]   
   >   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)