From: bc@freeuk.com   
      
   On 28/10/2025 06:45, Chris M. Thomasson wrote:   
   > On 10/27/2025 7:59 PM, Keith Thompson wrote:   
   >> "Chris M. Thomasson"  writes:   
   >>> On 10/27/2025 5:30 PM, Keith Thompson wrote:   
   >>> [...]   
   >>>   
   >>>> I can imagine either an enhanced version of the GNU autotools,   
   >>>> or a new set of tools similar to it, that could support building   
   >>>> software from source on Windows.   
   >>>   
   >>> https://vcpkg.io/en/packages?query=   
   >>>   
   >>> Not bad, well for me, for now. Builds like a charm, so far.   
   >>>   
   >>> [...]   
   >>   
   >> Looks interesting, but I don't think it's quite what I was talking about   
   >> (based on about 5 minutes browsing the website).   
   >   
   > So far, it can be used to cure some "headaches" over in Windows land... ;^)   
   >   
   >>   
   >> It seems to emphasize C and C++ *libraries* rather than applications.   
   >> And I don't see that it can be used to build an existing autotools-based   
   >> package (like, say, cdecl) on Windows.   
   >>   
   >   
   > Well, if what you want is not in that list, you are shit out of   
   > luck. ;^) It sure seems to build packages from source. For instance, I   
   > got Cairo compiled and up and fully integrated into MSVC. Pretty nice.   
   >   
   > At least its there. Although if it took a while to build everything,   
   > Bart would be pulling his hair out. But, beats manually building   
   > something that is not meant to be built on windows, uggg, sometimes,   
   > double uggg. Ming, cygwin, ect... vcpkg, has all of them, and used them   
   > to build certain things...   
   >   
   > I have built Cairo on Windows, and vcpkg is just oh so easy. Well, keep   
   > in mind, windows... ;^o   
   >   
      
   PART I   
      
   In the early days of testing my C compiler, I tried to build a   
   hello-type test program using GTK2.   
      
   GTK2 (I expect GTK4 is a lot worse!) was a complex library:   
      
   * There were some 700 include files, spread over a dozen or two nested   
   directories   
      
   * Compiling my test involved over 1000 nested #include statements, 550   
   unique header files, a dozen include search paths, and 330,000 lines of   
   declarations to process   
      
   * To link the result, GTK2 comes with 50 DLL files, totalling 50MB,   
   although not all will be needed. All have version names, so it's not   
   just a case of suppying a particular file name, it needs to have the   
   correct version suffix.   
      
   I managed this by trial and error. The input to the compiler needs to be:   
      
   * A set of search paths to the needed include files   
      
   * The exact names of the needed DLL files (their location is not needed,   
   provided the location is part of the Windows 'Path' variable)   
      
   Note we are not building anything from source; it is the simpler task of   
   using a ready-built library! The test program might be two dozen lines of C.   
      
   So, how does it all work normally? Apparently it's done with a program   
   called 'PKG-CONFIG' which performs some magic based on some 'metadata'   
   somewhere.   
      
   However this was of no interest to me: I wanted a bare-compiler solution   
   with minimal meta-dependencies   
      
   PART II   
      
   At a different point, I wanted to try GTK2 from my own language. Here   
   the sticking point is creating bindings, in my syntax, for the 10,000   
   functions, types, structs, enums, and macros exported by the library.   
      
   My C compiler has an extension which could do some of that   
   automatically: it processes the library headers (via the method in Part   
   I), and generated a single, flattened interface file containing all the   
   necessary information.   
      
   For GTK2, this was a single 25Kloc file, which I called gtk2.m. In my   
   language, I would compile the library by having 'import gtk2' in one   
   place in the program.   
      
   However, 4000 of those 25000 lines were C macros; simple #defines could   
   be converted, but the rest needed manual translation: a big task. (The   
   method has worked however for smaller libraries like OpenGL and SDL2.)   
      
   But here's the interesting thing: if, instead of generating bindings in   
   my syntax, suppose I generated them as C?   
      
   Then, instead of 700 headers, 1/3 million lines and dozens of folders,   
   the GTK2 API could be expressed in a single 25Kloc header file.   
      
   Why isn't such a process done anyway by the suppliers of the library?   
      
   (SDL2 would also reduce from 80 headers of 50Kloc, to one header of 3Kloc.)   
      
   PART III   
      
   This was an idea I had for my language, but it never got implemented.   
      
   At this point, a simple external library involves one or more DLL files,   
   and an interface file needed by the compiler, which gives the API info.   
      
   My idea was, why not put that interface file inside the DLL? Then you   
   submit that DLL name to the compiler, and it can extract the necessary   
   info, either via some special function, or an exported set of variables.   
      
   Where the DLL structure is complex, like GTK2, there could be an   
   accompanying small DLL that replaces those 700 files of headers. One   
   with an obvious name, like 'gtk2.dll'.   
      
   (In my language, such input gets specified once inside the lead module.   
   Building any app is always 'mm prog'.)   
      
   However, one remaining problem is finding where the DLL is located.   
      
   Again, the idea could work in C too.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)