From: bc@freeuk.com   
      
   On 30/10/2025 23:44, Keith Thompson wrote:   
   > bart  writes:   
   >> On 30/10/2025 18:59, Kaz Kylheku wrote:   
   >>> On 2025-10-30, bart  wrote:   
   >>>> On 30/10/2025 15:04, David Brown wrote:   
   >>>>> On 30/10/2025 13:07, bart wrote:   
   >>>>   
   >>>>> You moan that compiles are too slow.  Yet doing them in parallel is a   
   >>>>> "workaround".  Avoiding compiling unnecessarily is a "workaround".   
   >>>>> Caching compilation work is a "workaround".  Using a computer from this   
   >>>>> century is a "workaround".  Using a decent OS is a "workaround".  Is /   
   >>>>> everything/ that would reduce your scope for complaining loudly to the   
   >>>>> wrong people a workaround?   
   >>>>   
   >>>> Yes, they are all workarounds to cope with unreasonably slow compilers.   
   >>> The idea of incremental rebuilding goes back to a time when   
   >>> compilers   
   >>> were fast, but machines were slow.   
   >>   
   >> What do you mean by incremental rebuilding? I usually talk about   
   >> /independent/ compilation.   
   >>   
   >> Then incremental builds might be about deciding which modules to   
   >> recompile, except that that is so obvious, you didn't give it a name.   
   >>   
   >> Compile the one file you've just edited. If it might impact on any   
   >> others (you work on a project for months, you will know it   
   >> intimately), then you just compile the lot.   
   >   
   > I'll assume that was a serious question.  Even if you don't care,   
   > others might.   
   >   
   > Let's say I'm working on a project that has a bunch of *.c and   
   > *.h files.   
   >   
   > If I modify just foo.c, then type "make", it will (if everything   
   > is set up correctly) recompile "foo.c" generating "foo.o", and   
   > then run a link step to recreate any executable that depends on   
   > "foo.o".  It knows it doesn't have to recompile "bar.c" because   
   > "bar.o" sill exists and is newer than "bar.c".   
   >   
   > Perhaps the project provides several executable programs, and   
   > only two of them rely on foo.o.  Then it can relink just those   
   > two executables.   
   >   
   > This is likely to give you working executables substantially   
   > faster than if you did a full rebuild.  It's more useful while   
   > you're developing and updating a project than when you download   
   > the source and build it once.   
      
   I never came across any version of 'make' in the DEC OSes I used in the   
   1970s, in the 1980s did see it either.   
      
   In any case it wouldn't have worked with my compiler, as it was not a   
   discrete program: it was memory-resident together with an editor, as   
   part of my IDE.   
      
   This helped to get fast turnarounds even on floppy-based 8-bit systems.   
      
   Plus, I wouldn't have felt the issue was of any great importance:   
      
   When you're working intensely on a project for weeks or months, you will   
   be dealing with a thousand functions, variables and constants that you   
   have to keep organised in your mind.   
      
   Keeping track of which modules needed recompiling was child's play (and   
   I don't mean that literally!).   
      
   Anyway, with the language I was using at that time, modules had a   
   particular organisation:   
      
      * Most were modules containing code   
      * Some were classed as headers (only vaguely related to C headers),   
        which contained shared, project-wide declarations   
      * All modules shared the same set of headers (on compilation, all the   
        headers were treated as one, via an IDE-synthesised header that   
        included the rest)   
      
   Edits to code modules only needed that module recompiled. A change to   
   any header could require all to be recompiled, but that was at your   
   discretion.   
      
      
      
   > (I often tend to do full rebuilds anyway, for vague reasons I won't   
   > get into.)   
   >   
   > This depends on all relevant dependencies being reflected in the   
   > Makefile, and on file timestamps being updated correctly when files   
   > are edited.  (In the distant past, I've run into problems with the   
   > latter when the files are on an NFS server and the server and client   
   > have their clocks set differently.)   
   >   
   > (I'll just go ahead and acknowledge, so you don't have to, that   
   > this might not be necessary if the build tools are infinitely fast.)   
   >   
   > If I've done a "make clean" or "git clean", or started from scratch   
   > by cloning a git repo or unpacking a .tar.gz file, then any generated   
   > files will not be present, and typing "make" will have to rebuild   
   > everything.   
   >   
   > [...]   
   >   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)