Re: bin/50194: teach make about zip files

[David Holland <dholland-bugs%netbsd.org@localhost>]

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, 6 Sep 2015 00:03:22 +0000

 On Thu, Sep 03, 2015 at 09:05:00AM +0000, Joerg Sonnenberger wrote:
  >  On Thu, Sep 03, 2015 at 07:40:01AM +0000, dholland%netbsd.org@localhost wrote:
  >  > Make has a dusty and disused feature where it can look inside ar files
  >  > in order to address individual members and write rules about them.
  >  > This allows, for example, updating single files within static
  >  > libraries after recompiling.
  >  
  >  IMO this is a historic feature from the age where memory was extremely
  >  tight and doing anything on more than a single file was prohibitive. I
  >  don't think it should be extended and the general lack of equivalent
  >  functionality in most other build systems is a good indicator that it
  >  isn't all that useeful.
 
 I'm not convinced of that - it is dusty and disused for at least two
 other reasons; one being that ar is nearly useless, the other being
 that since the advent of shared libraries it doesn't make sense to do
 anything with single files in static libraries because that doesn't
 work for shared libraries.
 
 For jar files or the like (Java is not the only language environment
 to have hit on the notion of using zip files of compile results in
 place of linking) it can be used to avoid storing two copies of every
 build product on your disk; which is perhaps not that important given
 the cost of disk space, but it also doesn't cost very much to do.
 
 There's a second motivation though, which is that for any language
 where the interface definition of a module is a build product rather
 than an input, one wants make to be able to address the interface
 definition and the object file separately. If these come out as a
 single file, make needs to be able to look inside it; however, if
 these come out as two files, then we hit the problem where make chokes
 on multiple targets on the left of a rule.
 
 (This assumes that if you have
 
    foo.out: foo.src
 	$(COMPILE) foo.src
    bar.src: foo.out(foo.h)
 	$(COMPILE) bar.src
 
 that make will handle the dep through foo.out and foo.h properly; but
 if it doesn't currently it's fairly readily fixed, whereas the problem
 with multiple targets on the left is syntactic.)
 
 Granted it's a somewhat hypothetical situation but we could use it as a
 workaround for the base build problems with yacc output.
 
 -- 
 David A. Holland
 dholland%netbsd.org@localhost