On Fri, 12 Apr 2002 17:54:19 +1000, Keith Owens <[EMAIL PROTECTED]> wrote: >On Fri, 12 Apr 2002 17:05:56 +1000, >Brendan J Simon <[EMAIL PROTECTED]> wrote: >>I'd like to request a minor change to the makefile rules to generate >>targets. Could each rule start with removing the target. >> >>Example: >>%.o : %.c >> $(CC) $(CFLAGS) -c -o $@ $< >> >>becomes: >>%.o : %.c >> $(RM) $@ >> $(CC) $(CFLAGS) -c -o $@ $< > >This should already be occurring during the pp_makefile4 processing.
ps. GNU cc and ld also unlink the taregt file, they do not directly overwrite it. Both programs create a temporary file then rename it, which unlinks the original first. # ls -l x*.o -rwxr-xr-x 1 kaos ocs 13656 Apr 12 20:46 x1.o* lrwxr-xr-x 1 kaos ocs 4 Apr 12 20:46 x.o -> x1.o* # gcc x.c -o x.o # ls -l x*.o -rwxr-xr-x 1 kaos ocs 13656 Apr 12 20:46 x1.o* -rwxr-xr-x 1 kaos ocs 13656 Apr 12 20:47 x.o* Breaks the symlink and creates a new file. You get problems with symlinks when code does command > x.o that will follow the symlink. Some user commands might do that, but compile and link do not have that problem. Even with user_command() for a linked target, pp_makefile4 processing should remove the target first. Where you will hit problems are the pre-processing programs themselves. As I said earlier, kbuild was designed to not allow symlinks. Almost all the pp code assumes that it can just write to its output files. If the output file exists and is a symlink to another tree then all hell will break loose. That will not change until I have time to review the impact of symlinks on the entire system. _______________________________________________ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
