Re: [kbuild-devel] makefile rules request
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-x1 kaos ocs 13656 Apr 12 20:46 x1.o* lrwxr-xr-x1 kaos ocs 4 Apr 12 20:46 x.o -> x1.o* # gcc x.c -o x.o # ls -l x*.o -rwxr-xr-x1 kaos ocs 13656 Apr 12 20:46 x1.o* -rwxr-xr-x1 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
Re: [kbuild-devel] makefile rules request
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. That code detects when a target exists but the database is not marked up to date so pp_makefile4 removes the target. It also detects if any of the dependencies (including the source) have changed and removes the target. Run with PP_MAKEFILE4_FLAGS=-vvv to see what it thinks about up to date processing. It is the removal of the target file by pp_makefile4 that forces make to rebuild the target. The alternative is to give make the entire dependency tree in the global makefile, but then the compile time goes exponential. Of course this only works as long as you run pp_makefile4. If you bypass the checks using NO_MAKEFILE_GEN then ... foot, gun, shoot ... ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] makefile rules request
Keith, 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 $@ $< The main reason is to satisfy some configuration management systems (Aegis in my case) where files in a changeset (a local sandbox for a particular change) are sym-linked to *ALL* files in the repository (including all objects and generated files). The reason for this is that multiple users with multiple changesets do not have to recompile files that have not changed as they refer to the existing objects, libraries, executables and other generated files that are in the repository. This can make development of large projects significantly faster. The $(RM) command effectively removes the link and the generated file will be created in the changeset directory until it finally is integrated (committed/checked-in) to the repository. Some dependency maintenance tools have a setting to force removal of targets if it has to be remade. eg. cook has the "set unlink;" directive but I haven't been able to find an equivalent for GNU Make. If there is then this would be a better solution. ie. a one line change :) At the moment I'm forcing Aegis to copy all files from the repository to the changeset for two reasons. 1) kbuild-2.5 does not support source files that are symbolic links. I tried hard-links but then I run into problem #2. 2) The I know these are probably not high priorities for kbuild as most developers use less restricting CM tools (cvs generally), but the changes would not effect current users and would make it easier for users of other CM systems. I could supply patches for the $(RM) option if you don't object to these changes and would be likely to incorporate them into future kbuild releases. Thanks, Brendan Simon. ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
