From: xavi92@disroot.org   
      
   I agree that upstream Makefile is not of much value. In fact, slcl defines   
   their own from a parent directory so fdzipstream can be effectively used as a   
   library. [1][2]   
      
   Telling upstream to provide a more useful/meaningful build system would be a   
   good suggestion IMHO. But how much of a hard requirement is this from the   
   perspective of Debian packaging?   
      
   Best regards,   
   Xavi   
      
   [1]: https://codeberg.org/xavidcr/slcl/src/commit/1e93a53bc43e51   
   1346d9cca64d2dd3b25c0e4ca/fdzipstream/Makefile   
   [2]: https://codeberg.org/xavidcr/slcl/src/commit/1e93a53bc43e51   
   1346d9cca64d2dd3b25c0e4ca/fdzipstream/CMakeLists.txt   
      
   On 14 February 2026 10:34:14 CET, "Preuße, Hilmar"  wrote:   
   >Am 14.02.2026 um 00:22 schrieb Xavier Del Campo Romero:   
   >   
   >Hello,   
   >   
   >> As opposed to zip(1), fdzipstream is not an executable, but a C library. It   
   is therefore meant to be embedded into other applications, adding zlib as its   
   only dependency. For example, slcl [1] embeds fdzipstream to compress zip   
   files on-the-fly from C    
   (and send them over the network), rather than having to rely on an external   
   process as you suggested.   
   >>    
   >The upstreams Makefile [1] currently just generates two executables   
   >   
   >all: zipexample zipfiles   
   >   
   >What am I missing?   
   >   
   >Hilmar   
   >   
   >[1] https://github.com/CTrabant/fdzipstream/blob/main/Makefile   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)