[PATCH] Fix move-if-change for VPATH builds

Nick Clifton nickc@redhat.com
Mon Jan 7 08:54:00 GMT 2008


Hi Dmitry,

> What I suggest is making "move-if-change" aware of the directory where
> building is performed by passing "$(srcdir)" to it as the first
> argument. The only change in the algorithm is adding the following rule:
> "If the destination file "dstfile" is the same as the source file and
> the destination file doesn't exist in the current directory, then create
> a symbolic link "dstfile" pointing to "$(srcdir)/dstfile".

It seems to me that this patch changes the semantics of move-if-change quite 
considerably.  Before:

   move-if-change foo bar

meant:

    "In the current directory replace bar with foo if they are different
     or if bar does not exist, and then regardless of whether the
     replacement happened, delete foo".

with the patch applied we would have:

   move-if-change <srcdir> foo bar

meaning:

   "In the current directory replace bar with foo, but only if foo is
    different from some other file <srcdir>/bar or if <srcdir>/bar does not
    exist.  If <srcdir>/bar does not exist then go ahead with the replacement
    even if foo and bar are the same.  Then regardless of whether the
    replacement happened, delete foo, but if the replacement did not happen
    and bar does not exist then create a symbolic link called bar back to
    <srcdir>/bar."

My points are:

    a) If SRCDIR/DEST does not exist then the patched script will always move 
SOURCE to DEST even if they both exist and are both the same.

    b) The script's behaviour is no longer "like mv $1 $2", so the comment at 
the start ought to be changed.

    c) The patched script assumes that symbolic links can be created - this is
not true of all file systems and all OSes.

Hence as it stands I do not think that the patch is suitable for inclusion into 
the sources.  Plus as DJ mentioned you will need buy-in from the GCC and GDB 
projects before a patch like this can be applied, so you will need to propose 
it to them as well.

Cheers
   Nick



More information about the Binutils mailing list