Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #8290

Re: Incremental build systems, infamake

Cross-posted to 2 groups.

Show all headers | View raw

On Mon, 25 Jul 2011 13:34:52 -0700, Joshua Maurice wrote:

> I don't know if you read my entire post, and I don't know if you mean
> a literal "list of dependencies" or a figurative list and some more
> complex handling. If you merely keep track of a list of /file/
> dependencies, then this is completely insufficient. Changing command
> line options won't trigger a rebuild, removing a cpp file won't delete
> its corresponding object file and relink its corresponding lib or
> executable, adding a new header file which hides a previously included
> header file on the include path won't trigger a rebuild, etc.

As I said:

>> Ensuring correctness of incremental builds boils down to ensuring that
>> the list of prerequisites for each target is "adequate".

You can handle the above issues with any "make" program; you just have to
specify the correct prerequisites.

E.g. any directory which will be searched by the compiler or linker needs
to be specified as a prerequisite, as does all of its parent directories
(and also /etc/mtab; mounting a directory won't update the modification
time of the mount point). This will cause the target to be rebuilt if
files are added or removed from those directories, or if renaming
causes the directory's pathname to refer to a different directory).
However, it will do so regardless of whether the change would actually
affect the target (i.e. it's a sufficient condition rather than a
necessary one).

For data which isn't a file (this includes devices and pseudo-files such
as /proc/* whose timestamps aren't meaningful), you can achieve the
desired behavour with e.g.:

	echo $ENVVAR > envvar-value.tmp
	if cmp envvar-value envvar-value.tmp ; then \
	  rm envvar-value.tmp ; \
	else \
	  mv envvar-value.tmp envvar-value ; \
	fi

A similar approach could be used for a more accurate version of the header
search issue above, by using e.g. "gcc -E -MM ..." (list dependencies) to
generate a dependency list, and using that as a prerequisite.

then listing envvar-value as a prerequisite to any target which will
be affected by changes to $ENVVAR.

> As I said, I want to at least capture the common actions so that a
> developer feels safe doing a source control get latest, then an
> incremental build, and trust that things will just work.

So you want make to automatically determine the prerequisites for a target?

You could do that by ptrace()ing all of the commands used to build a
target. Determining whether a target needs to be rebuilt would involve
determining whether any of the system calls involved will return different
data. But that would result in unnecessary work; just because a system
call returns different data, it doesn't automatically follow that the
target will actually change; the target may actually only use a small
portion of the data returned (e.g. a single macro from a large header file).

Also, even if the target would change, it doesn't follow that it should be
rebuilt. E.g. any source file using __TIME__ will result in an object file
which always changes, but that doesn't mean that you want to rebuild it.

> A change to C.java requires a rebuild of B.java, but it does not require
> a rebuild of A.java (usually). You need something more interesting than
> an unconditional cascading rebuild to make this work out right while
> doing the incremental thing and trying to skip unnecessary parts of the
> build.

That would require a slight change to "make". Specifically, you'd need to
check whether a target's timestamp was actually changed, and only cascade
if it did. But note that this would reduce the potential for parallelism.

If you did that, then you could deal with the issue by restoring the
timestamp if the new file is "equivalent" to the old one.

Back to comp.lang.c++ | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Incremental build systems, infamake Joshua Maurice <joshuamaurice@gmail.com> - 2011-07-25 00:25 -0700
  Re: Incremental build systems, infamake Ian Collins <ian-news@hotmail.com> - 2011-07-25 21:00 +1200
    Re: Incremental build systems, infamake Joshua Maurice <joshuamaurice@gmail.com> - 2011-07-25 02:11 -0700
      Re: Incremental build systems, infamake Ian Collins <ian-news@hotmail.com> - 2011-07-25 21:33 +1200
        Re: Incremental build systems, infamake Joshua Maurice <joshuamaurice@gmail.com> - 2011-07-25 02:38 -0700
          Re: Incremental build systems, infamake Ian Collins <ian-news@hotmail.com> - 2011-07-25 21:55 +1200
          Re: Incremental build systems, infamake Joshua Maurice <joshuamaurice@gmail.com> - 2011-07-25 03:04 -0700
            Re: Incremental build systems, infamake Ian Collins <ian-news@hotmail.com> - 2011-07-25 22:22 +1200
              Re: Incremental build systems, infamake Joshua Maurice <joshuamaurice@gmail.com> - 2011-07-25 03:25 -0700
                Re: Incremental build systems, infamake Ian Collins <ian-news@hotmail.com> - 2011-07-25 23:41 +1200
            Re: Incremental build systems, infamake Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-07-26 16:11 +0000
              Re: Incremental build systems, infamake Joshua Maurice <joshuamaurice@gmail.com> - 2011-07-26 15:19 -0700
                Re: Incremental build systems, infamake Joshua Maurice <joshuamaurice@gmail.com> - 2011-07-26 15:28 -0700
                Re: Incremental build systems, infamake Joshua Maurice <joshuamaurice@gmail.com> - 2011-07-26 15:49 -0700
  Re: Incremental build systems, infamake Nobody <nobody@nowhere.com> - 2011-07-25 12:52 +0100
    Re: Incremental build systems, infamake Joshua Maurice <joshuamaurice@gmail.com> - 2011-07-25 13:34 -0700
      Re: Incremental build systems, infamake Nobody <nobody@nowhere.com> - 2011-07-27 19:49 +0100
        Re: Incremental build systems, infamake Joshua Maurice <joshuamaurice@gmail.com> - 2011-07-29 03:58 -0700
  Re: Incremental build systems, infamake Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-07-26 15:04 +0000

csiph-web