I use strace(1) look for stat(2) syscalls that fail with ENOENT. An advantage of this approach is that I do not have to imitate the C preprocessor, so parser differentials can never happen. The following default.o.do file from my blog post [1] handles the case: #!/bin/sh
redo-ifchange $2.c
strace -e stat,stat64,fstat,fstat64,lstat,lstat64 -f 2>&1 >/dev/null\
gcc $2.c -o $3 -MD -MF $2.deps\
|grep '1 ENOENT'\
|grep '\.h'\
|cut -d'"' -f2 2>/dev/null\
>$2.deps_ne
read d <$2.deps
redo-ifchange ${d#*:}
while read -r d_ne; do
redo-ifcreate $d_ne
done <$2.deps_ne
chmod a+x $3
This approach is also used for building Liberation Circuit if strace is installed [2].I think the compiler should output the necessary information. To quote Jonathan de Boyne Pollard [3]: > As noted earlier, no C or C++ compiler currently generates any redo-ifcreate dependency information, only the redo-ifchange dependency information. This is a deficiency of the compilers rather than a deficiency of redo, though. That the introduction of a new higher-precedence header earlier on the include path will affect recompilation is a fact that almost all C/C++ build systems fail to account for. > I have written, but not yet released, a C++ tool that is capable of generating both redo-ifchange information for included files and redo-ifcreate information for the places where included files were searched for but didn't exist, and thus where adding new (different) included files would change the output. JdeBP, could you please release your tool under a free software license? I suspect it has fewer errors than the similar CMake approach [4]. [1] http://news.dieweltistgarnichtso.net/posts/redo-gcc-automati... [2] https://github.com/linleyh/liberation-circuit/blob/master/sr... [3] http://jdebp.eu./FGA/introduction-to-redo.html#CompilerDefic... [4] https://github.com/Kitware/CMake/blob/master/Source/cmDepend... |