NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: bin/50194: teach make about zip files



The following reply was made to PR bin/50194; it has been noted by GNATS.

From: David Holland <dholland-bugs%netbsd.org@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: bin/50194: teach make about zip files
Date: Sun, 29 Jun 2025 21:43:16 +0000

 On Sun, Jun 29, 2025 at 07:10:02AM +0000, Roland Illig via gnats wrote:
  >  I'm not convinced that zip files can solve the yacc issue. But even if
  >  so, it would already be possible with ar files, thus we wouldn't need
  >  zip support.
 
 IIRC the basic idea was something like
 
    foo.zip: foo.y
            yacc -d foo.y
            zip $@ y.tab.h y.tab.c
    foo.h: foo.zip
            unzip -d tmp foo.zip y.tab.h
            mv tmp/y.tab.h foo.h
    foo.c: foo.zip
            unzip -d tmp foo.zip y.tab.c
            mv tmp/y.tab.c foo.c
 
 Which does work, it's just messy and ugly and wastes cycles. IIRC
 around the time this PR got filed someone had suggested something like
 this.
 
 You could use ar instead; the problem with that is that storing
 anything other than .o files in ar isn't portable/doesn't work
 reliably/isn't recommended/whatever. (It worked for me when I tried it
 just now, but I also remember having had problems in the past.)
 
 The utility in this context of being able to look in the zip file to
 depend on the files inside it is pretty limited. What I wrote ten
 years ago kind of suggests I had something further in mind, but if so
 I've long forgotten what.
 
 However, I'm pretty sure the original motivation for filing this PR
 was trying to deal with jar files or possibly some boutique language's
 equivalent of them.
 
 In that context:
 
  >  I tried to understand how other programs would then work with the files
  >  inside the archive, but I didn't manage to understand it. Only very few
  >  programs are able to look inside ar files or zip files.
 
 That does, however, include the linking tools that use jar files and
 similar as input. So in particular you might reasonably write
 something like
 
    foo.class: foo.java
            javac foo.class
    lib.jar(foo.class): foo.class
            zip add lib.jar foo.class
 
 or even
 
    lib.jar(foo.class): foo.java
            javac foo.class
            zip add lib.jar foo.class
            rm -f foo.class
 
 (generalized over SRCS in any of the usual ways)
 
 Basically, a number of language environments now use zip files the way
 traditional Unix uses ar files. Therefore, it's reasonable to support
 looking inside zip files the same way make supports looking inside ar
 files.
 
 Note that this doesn't require being able to examine file contents so
 it doesn't require implementing anything complicated, just examining
 zip headers.
 
 -- 
 David A. Holland
 dholland%netbsd.org@localhost
 


Home | Main Index | Thread Index | Old Index