bug-make
[Top][All Lists]
Advanced

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

Re: [PATCH] Options: `--dry-run' should prevent `--touch' from touching


From: Michael Witten
Subject: Re: [PATCH] Options: `--dry-run' should prevent `--touch' from touching
Date: Thu, 24 Mar 2011 03:52:59 -0500

On Tue, Mar 8, 2011 at 18:12, Michael Witten <address@hidden> wrote:
> On Tue, Mar 8, 2011 at 16:11, Philip Guenther <address@hidden> wrote:
>> On Tue, Mar 8, 2011 at 1:37 PM, Michael Witten <address@hidden> wrote:
>>> The `--dry-run' flag is supposed to be safe in that nothing
>>> in the file system is actually modified.
>>
>> That's not actually true.  To quote the docs:
>>
>> `-n'
>> `--just-print'
>> `--dry-run'
>> `--recon'
>>     "No-op".  The activity is to print what recipe would be used to
>>     make the targets up to date, but not actually execute it.  Some
>>     recipes are still executed, even with this flag (*note How the
>>     `MAKE' Variable Works: MAKE Variable.).
>>
>> and then later on the same page:
>>
>>   The `-n', `-t', and `-q' options do not affect recipe lines that
>> begin with `+' characters or contain the strings `$(MAKE)' or
>> `${MAKE}'.  Note that only the line containing the `+' character or the
>> strings `$(MAKE)' or `${MAKE}' is run regardless of these options.
>> Other lines in the same rule are not run unless they too begin with `+'
>> or contain `$(MAKE)' or `${MAKE}' (*Note How the `MAKE' Variable Works:
>> MAKE Variable.)
>>
>>
>> At least part of that behavior is required by the POSIX specification
>> and has a few decades of history behind it.
>
> Well, ok, but my patch still stands.
>
> According to [the development version of]:
>
>  info '(make)Instead of Execution'
>
> we have:
>
>  `-t'
>  `--touch'
>       "Touch".  Marks targets as up to date without actually changing
>       them.  In other words, `make' pretends to update the targets but
>       does not really change their contents; instead only their modified
>       times are updated.
>
> Comparing this with the text quoted for `--dry-run', it can be seen that
> the operative words here are:
>
>  `--dry-run'
>      The activity is to print what recipe would be used
>      TO MAKE THE TARGETS UP TO DATE, but not actually
>      execute it.
>
>  `--touch'
>       MARKS TARGETS AS UP TO DATE without actually changing.
>
> Similarly, this is what my system's POSIX documentation:
>
>  man 1p make
>
> has to say:
>
>  -n     Write commands that would be executed on standard output, but
>         do not execute them. However, lines with a plus sign ( '+' )
>         prefix shall be executed. In this mode, lines with an at sign
>         ( '@' ) character prefix shall be written to standard output.
>
>  -t     Update the modification time of each target as though a
>         `touch target' had been executed. Targets that have
>         prerequisites but no commands (see Target Rules ), or that
>         are already up-to-date, shall not be touched in this manner.
>         Write messages to standard output for each target file
>         indicating the name of the file and that it was touched.
>         Normally, the makefile command lines associated with each
>         target are not executed. However, a command line with a plus
>         sign ( '+' ) prefix shall be executed.
>
> In particular:
>
>  -n     Write COMMANDS THAT WOULD BE EXECUTED on standard output, but
>         do not execute them.
>
>  -t     Update the modification time of each target AS THOUGH A
>         `touch target' HAD BEEN EXECUTED.
>
> Indeed, `-t' is not simply a directive to touch the targets; in large
> part, it is meant to act as a substitute for the `recipe' (except for
> special command lines detailed above):
>
>  -t     ... Targets that have prerequisites but no commands (see Target
>         Rules ), or that are already up-to-date, shall not be touched
>         in this manner.
>
> Thus, it makes most sense for `--dry-run' (`-n') to mask `--touch' (`-t')
> rather than the other way around (which is the current, buggy, unexpected,
> possibly ruinous behavior).
>
> Sincerely,
> Michael Witten
>

Um... Hello?



reply via email to

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