Re: bsd.lib.mk question

[Masao Uebayashi <uebayasi%gmail.com@localhost>]

On Wed, Jun 8, 2011 at 3:36 AM, David Holland 
<dholland-tech%netbsd.org@localhost> wrote:
> 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.

Details can be hidden.  Is there any other problem?

The only rule we have to remember is, "generate one file at one time".
 If some command violates this rule, you need a little care (apply a
wrapper command).  Otherwise rules can be written simple.  No race, no
side-effect, full parallel build.

The only problem is inefficiency - but considering the amount of such
multiple generation commands, it's ignorable.