help-make
[Top][All Lists]
Advanced

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

Re: Advanced Auto-Dependency Generation. A slight improvement.


From: Nick Patavalis
Subject: Re: Advanced Auto-Dependency Generation. A slight improvement.
Date: Wed, 1 Feb 2006 11:15:10 +0200
User-agent: Mutt/1.5.9i

On Wed, Feb 01, 2006 at 04:01:13AM +0000, Greg Chicares wrote:
> 
> A similar idea is presented here:
>   http://lists.gnu.org/archive/html/help-make/2004-01/msg00058.html
> and you might be interested in the ensuing discussion.
>

I read the discussion. Among other things they seem to suggest that
rule command sets must be written in a "transactional" fashion. I
couldn't agree more. If the commands create *only* the target file,
then simply listing them in order is enough. If one command fails,
make will "cancel the transaction" (so to speak) by not running the
remaining commands and removing the target file: ::

   command 1;
   command 2; <--- if this fails then command 3 will not run, 
   command 3;      and the target will be deleted.

The problem arises if the commands have side-effects. In this case
special care must be taken to cancel all side-effects if the
command-sequence fails. I can think of two solutions for this. One is:
::

  { create a \
    && create b \
    && create c; \
  } || { rm -f a b c; false; }

and the other: ::

  trap "rm -f a b c; exit 1" ERR HUP INT TERM; \
  create a; \
  create b; \
  create c

On the outset they seem equivalent, but are they? 

I believe the second approach, while uglier, is more reliable.  In the
first case there seems to be a possibility that the transaction will
remain half-completed if the shell is killed by a signal after having
created some of the files. The second approach, while uglier and less
"portable", does not suffer from this.

If we are concerned about only a single "side-effect file" (call it
"a"), then a much cleaner, and much more reliable, solution would be
along the lines of:

  create a.xx;
  modify a.xx;
  modify a.xx;
  mv a.xx a;

This takes advantage of the atomic nature of file moves. But if more
than one side-effect files are involved I can't think of a way to do
something like this. The "trap" solution above is, in such cases, the
best I can think of.

/npat

-- 
He who joyfully marches to music in rank and file has already earned
my contempt.  He has been given a large brain by mistake, since for
him the spinal cord would fully suffice.
  -- Albert Einstein




reply via email to

[Prev in Thread] Current Thread [Next in Thread]