From: david.brown@hesbynett.no   
      
   On 25/10/2025 17:48, bart wrote:   
   > 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'.   
   >   
      
   It uses yacc and lex for generating the parsing code.  Fair enough -   
   that's what those tools are for.   
      
   > 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).   
      
   Lots of people use *nix, or POSIX, or unix-like as single terms.  Most   
   software that is for "big" systems (rather than small embedded ones),   
   and is not Windows or Mac only, is *nix and works on various Unix   
   systems, Solaris, AIX, BSD, Linux, and a wide variety of related systems   
   - including *nix layers on Windows (msys2, cygwin, WSL, etc.).  On of   
   the reasons why such a lot of software is so widely portable is the   
   widespread use of autotools - with the common "./configure && make -j &&   
   make install" combination for building the software.  The "configure"   
   part handles the details and differences between the systems so that the   
   software is portable.   
      
   Now, everyone who has ever used this can see potential for improvement.   
   There are large numbers of checks that autotools does that are always   
   "yes" on most systems from the last decade.  But there are also people   
   who want to use software on their ancient Sun workstations, or their   
   big-endian MIPS machines.  And there are lots of people who want to   
   compile software on their machines but haven't installed various   
   libraries that are essential or potentially useful - configure will see   
   that and tell them about it.   
      
   So the autotools systems is very useful, and helps keep things highly   
   portable - but there is certainly a potential for improvement with   
   caching the results of the tests.  Maybe someday someone will feel   
   bothered enough by the 10 second configure that they will make such   
   improvements.   
      
      
   Yes, the whole thing is complicated.  But the complications are hidden,   
   so for the people using autotools builds, and who have some basic   
   familiarity with them, the process is simple and almost all automatic.   
   We can all be curious about what is going on behind the scenes, but you   
   can also just do the build and use the program without bothering about   
   these details.  Life is too short to try to understand /everything/.   
      
   >   
   > This is not specific to CDECL; it's nearly everything that comes of   
   > Unix-Linux. But this came up and I had a look.   
   >   
   > 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?   
   >   
      
   Would it have been possible?  Yes, of course.  Would it have been the   
   real source here?  No - the author used source generator tools like yacc   
   and lex to generate C code.  Would it have made the build process easier   
   or faster for normal users of the source code?  No - the typical person   
   who is interested in such software and is keen enough on getting the   
   very latest version, can build it in a couple of minutes at most.  Would   
   it help people who just want a binary for normal usage?  No, most would   
   just get cdecl from their package manager.  Generally speaking, if you   
   want binaries for such a program for Windows, you can google for it - if   
   an open source program is useful, someone will have made a windows   
   build.  Unfortunately in this case, googling for "windows cdecl binary"   
   is going to give you results for the "cdecl" calling convention for   
   MSVC, swamping any useful results.  Still, googling for "msys2 cdecl"   
   does fine.   
      
   I can appreciate that the way this program is written, and the way the   
   build process works, is awkward for /you/.  But I think you are a very   
   unique person, and the program and its build system are absolutely fine   
   for the vast majority of people who would want to get the source from   
   the github page.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)