From: Keith.S.Thompson+u@gmail.com   
      
   bart  writes:   
   > 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.   
      
   Eventually?  Once I cloned the repository, it took about 45 seconds to   
   build and install from source on my system, and I was able to run it   
   immediately.   
      
   I happen to have a script that automates much of the process that could   
   otherwise be done with about 3 commands.  Writing that script was   
   worthwhile *for me* because I happen to build a lot of autotools-based   
   packages from source.  Without that, it might have taken me several   
   minutes.   
      
   > That it favours your own OS, leaving users of other to have to jump   
   > through extra hoops, doesn't appear to bother you.   
      
   Why should it bother me?  I can certainly see that an easier way to   
   build cdecl on Windows would be a good thing, but it doesn't affect me.   
      
   [...]   
      
   > Well I built cdecl too, under WSL. Jesus, that looked a lot of work!   
      
   Really?  I built it under WSL myself, using exactly the same method I   
   used on my Ubuntu system.  Cygwin too.  The latter was a bit slow, but I   
   did other things while it was building.   
      
   Are you at all interested in learning how to build this kind of software   
   package more easily?  If so, email me.  This isn't really about C, so   
   I'd rather not dive into it too deeply here.   
      
   There are certainly things to dislike about autotools, but there are   
   thousands of software packages that use it.  Once you learn how to build   
   one such package, you can build most of them (at least in a Unix-like   
   environment).   
      
   No, it doesn't work well for Windows without a Unix-like emulation   
   layer.  Maybe it could be enhanced to work better on Windows.  Maybe you   
   could contribute to making that happen.   
      
   > However, it took me a while to find where it put the executable, as   
   > the make process doesn't directly tell you that. It seems it puts it   
   > inside the src directory, which is unusual. It further appears that   
   > you have to do 'make install' to be able to run it without a path.   
      
   That's not unusual -- and the "make install" step is common to hundreds   
   of software packages.  I usually don't notice where the executable   
   initially appears; "make install" puts it where I want it.   
      
   > (Yes, I did glance at the readme, but it is a .md file which I didn't   
   > notice, and in plain text it looked unreadable.)   
      
   Sure, it would be nice if the README.md were more legible.  Most of   
   them are.  Apparently the author was more interested in it being   
   readable using a markdown viewer.  But if you view the project's   
   site on GitHub, the README.md is formatted for you.   
      
   > When I did run it, then while it had a fair number of options, it   
   > didn't appear to do much beyond converting C declarations to and from   
   > an English description.   
   >   
   > That program is 2.8 MB (10 times the size of my C compiler).   
      
   As mentioned later in this thread, you didn't strip the executable.  It   
   might be nice if stripping the executable were the default.   
      
   > I guess you don't care about that either. But surely, you must be   
   > curious about WHY it is so big? You must surely know, with your   
   > decades of experience, that this is 100 times bigger than necessary   
   > for such a task?   
      
   How many lines of assembly language were generated and discarded during   
   compilation?  I'm guessing you don't know or care.  Why do you care so   
   much about other things that you don't need?   
      
   > I decided to make my own mini-cdecl. It took 20 minutes and works like this:   
   >   
   >   c:\cx>qq cdecl   
   >   Mycdecl> explain void (*f(int i))(void);   
   >   f = proc(i32)ref proc()void   
   >   Mycdecl> q   
      
   I doubt that that obscure syntax would be of interest to most people,   
   though I'm sure it works for you.  If you wanted to generate something   
   more readable by more users, you might have an interesting competitor to   
   cdecl.   
      
   [...]   
      
   --   
   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)