Re: bsd.lib.mk question

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

On Tue, Jun 07, 2011 at 10:21:22AM -0700, Simon J. Gerraty wrote:
 > >> With at least some makes, this will (possibly depending on timestamps)
 > >> cause parser.o to be recompiled from parser.c every time you type
 > >> make, because it's been "rebuilt" by the null rule. Furthermore, it's
 > 
 > You could simply add a touch to parser.c so that it is always newer that
 > parser.h 

Yes, I suppose that would work but it's still gross.

 > >> lying to make, which never works out well in the long run. The only
 > 
 > I've never noticed it get upset ;-)

...that's exactly what people said when they wrote a zillion other
questionable constructs that don't work right in make -j land. Or when
they wrote logic that depended on quirks of SVR4 make's builtin .c.o
rule, or tried to do without .WAIT by introducing spurious extra
dependencies, or whatever else.

The basic principle is: the makefile should state what you mean, not
just something arbitrary that seems to cause make to do more or less
the right thing. Then your stuff will keep working if the basic
assumptions change.

It's the responsibility of make to be expressive enough allow you to
state what you mean and not have to resort to semantic workarounds.

 > >What's wrong with the wrapper approach which wraps those commands to
 > >generate single output file?  This should work as long as those
 > >command output is reproducible.
 > 
 > I'm not sure I follow that.  
 > There are two files to be generated.

I'm guessing something like

   parser.tar: parser.y
           (cd $(SOMEUNIQUETMPDIR) && yacc -d && 
            tar -cf - parser.c parser.h) > parser.tar

   parser.h: parser.tar
           tar -xf parser.tar parser.h

   parser.c: parser.tar
           tar -xf parser.tar parser.c

which is I guess correct but horribly gross.

-- 
David A. Holland
dholland%netbsd.org@localhost