From: 643-408-1753@kylheku.com   
      
   On 2025-10-28, bart  wrote:   
   > On 28/10/2025 17:03, Kaz Kylheku wrote:   
   >> On 2025-10-28, bart  wrote:   
   >>> On 27/10/2025 20:52, Kaz Kylheku wrote:   
   >>>> On 2025-10-27, Keith Thompson  wrote:   
   >>>>> bart  writes:   
   >>>>> [...]   
   >>>>>> Yes, but: the development and build procedures HAVE BEEN BUILT AROUND   
   UNIX.   
   >>>>>>   
   >>>>>> So they are utterly dependent on them. So much so that it is pretty   
   >>>>>> much impossible to build this stuff on any non-UNIX environment,   
   >>>>>> unless that environment is emulated. That is what happens with WSL,   
   >>>>>> MSYS2, CYGWIN.   
   >>>>> [...]   
   >>>>>   
   >>>>> **Yes, you're right**.   
   >>>>>   
   >>>>> The GNU autotools typically work smoothly when used on Unix-like   
   >>>>> systems.  They can be made to work nearly as smoothly under Windows   
   >>>>> by using an emulation layer such as WSL, MSYS2, or Cygwin.  It's very   
   >>>>> difficult to use them on pure Windows.   
   >>>>   
   >>>> The way I see the status quo in this matter is this: cross-platform   
   >>>> programs originating or mainly focusing on Unix-likes require effort   
   >>>> /from their actual authors/ to have a native Windows port.   
   >>>>   
   >>>> Whereas when such programs are ported to Unix-like which their   
   >>>> authors do not use, it is often possible for the users to get it   
   >>>> working without needing help from the authors. There may be some   
   >>>> patch to upstream, and that's about it.   
   >>>>   
   >>>> Also, a proper Windows port isn't just a way to build on Windows.   
   >>>> Nobody does that. Windows doens't have tools out of the box.   
   >>>>   
   >>>> When you seriously commit to a Windows port, you provide a binary build   
   >>>> with a proper installer.   
   >>>   
   >>> The problem with a binary distribution is AV software on the user's   
   >>> machine which can block it.   
   >>   
   >> Well, then you're fucked. (Which, anyway, is a good general adjective   
   >> for someone still depending on Microsoft Windows.)   
   >>   
   >> The problem with source distribution is that users on Windows don't   
   >> have any tooling. To get tooling, they would need to install binaries.   
   >   
   > There seems little problem with installing well-known compilers.   
      
   If you think that is the case, then you can make an installer which   
   bundles some know compiler, and your source code ... and so it goes.   
      
   At install time, it builds the program.   
      
   The user doesn't care how the program came to be there.   
      
   (But even programs you build on the Windows machine itself can trigger   
   antivirus ...)   
      
   > An installer is just an executable like any other, at least if it as a   
   > .EXE extension.   
      
   Yes and, similarly, "there seems little problem with installing   
   well-known" installers.   
      
   > If you supply a one-file, self-contained ready-to-run application, then   
   > it doesn't really need installing. Wherever it happens to reside after   
   > downloading, it can happily be run from there!   
      
   Yes; that would be nice. Many people get PuTTY.exe that way, for   
   instance.   
      
   > The only thing that's needed is to make it so that it can be run from   
   > anywhere without needing to type its path. But I can't remember any apps   
   > I've installed recently that seem to get that right, even with a   
   > long-winded installer:   
      
   I did that for the Windows port of the TXR language. The installer   
   updates PATH and sends the Windows message to running apps about the   
   environment change. IIRC, existing cmd.exe instances pick that up.   
      
   The generated uninstall.exe will take it right out.   
      
   I've not looked at this in ages. I seem to recall there is a check   
   against inserting the same PATH entry multiple times.   
      
   Anyway, once you have that working, it works.   
      
   In my inst.nsi, in Section "TXR" it looks like this;   
      
     ${If} $AccountType == "Admin"   
       ${EnvVarUpdate} $0 "PATH" "A" "HKLM" "$INSTDIR\txr\bin"   
     ${Else}   
       ${EnvVarUpdate} $0 "PATH" "A" "HKCU" "$INSTDIR\txr\bin"   
     ${Endif}   
      
   And in Section "Uninstall" the removal looks like this:   
      
     ${If} $AccountType == "Admin"   
       ${un.EnvVarUpdate} $0 "PATH" "R" "HKLM" "$INSTDIR\bin"   
     ${Else}   
       ${un.EnvVarUpdate} $0 "PATH" "R" "HKCU" "$INSTDIR\bin"   
     ${Endif}   
      
   Thus everything is done by this EnvVarUpdate, and its un.EnvVarUpdate   
      
   These two environment update functions come from an "env.nsh" file that   
   is not part of NSIS; it is a utility developed by multiple authors: Cal   
   Turney, Amir Szekely, Diego Pedroso, Kevin English, Hendri Adriaens and   
   others.   
      
   --   
   TXR Programming Language: http://nongnu.org/txr   
   Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal   
   Mastodon: @Kazinator@mstdn.ca   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)