Re: icc dependency generation

[Alexandre Duret-Lutz]

>>> "adl" == Alexandre Duret-Lutz <address@hidden> writes:

[...]

 adl> You mentioned that the depcomp configure test fails to
 adl> chose the icc mode.  What mode does it select presently?

Update: I've got the occasion to try ICC 7.1 (Build 20030617Z)
with automake 1.7.5 and I've found it is working fine.
./configure correctly selects the icc dependency tracking mode,
and when I try the small test from your first mail it works as
Automake expects:

~/tmp % : > conftest.c
~/tmp % rm -f foo.bar
~/tmp % icc -MD -MF foo.bar -c conftest.c
~/tmp % cat foo.bar
conftest.o: conftest.c

So I'm quite puzzled by your report.


I'm assuming that if ./configure fails to select the icc mode,
it will use the tru64 mode (which is wrong for ICC).  The
following patch should allow ./configure to realize tru64 is not
good either.  Could you try it?

Index: m4/depend.m4
===================================================================
RCS file: /cvs/automake/automake/m4/depend.m4,v
retrieving revision 1.29
diff -u -r1.29 depend.m4
--- m4/depend.m4        11 Feb 2003 18:20:54 -0000      1.29
+++ m4/depend.m4        28 Jun 2003 23:08:32 -0000
@@ -61,6 +61,13 @@
   # using a relative directory.
   cp "$am_depcomp" conftest.dir
   cd conftest.dir
+  # We will build objects and dependencies in a subdirectory because
+  # it helps to detect inapplicable dependency modes.  For instance
+  # both Tru64's cc and ICC support -MD to output dependencies as a
+  # side effect of compilation, but ICC will put the dependencies in
+  # the current directory while Tru64 will put them in the object
+  # directory.
+  mkdir sub
 
   am_cv_$1_dependencies_compiler_type=none
   if test "$am_compiler_list" = ""; then
@@ -70,9 +77,9 @@
     # We need to recreate these files for each test, as the compiler may
     # overwrite some of them when testing with obscure command lines.
     # This happens at least with the AIX C compiler.
-    echo '#include "conftest.h"' > conftest.c
-    echo 'int i;' > conftest.h
-    echo "${am__include} ${am__quote}conftest.Po${am__quote}" > confmf
+    echo '#include "conftest.h"' > sub/conftest.c
+    echo 'int i;' > sub/conftest.h
+    echo "${am__include} ${am__quote}sub/conftest.Po${am__quote}" > confmf
 
     case $depmode in
     nosideeffect)
@@ -90,11 +97,12 @@
     # mode.  It turns out that the SunPro C++ compiler does not properly
     # handle `-M -o', and we need to detect this.
     if depmode=$depmode \
-       source=conftest.c object=conftest.o \
-       depfile=conftest.Po tmpdepfile=conftest.TPo \
-       $SHELL ./depcomp $depcc -c -o conftest.o conftest.c \
+       source=sub/conftest.c object=sub/conftest.${OBJEXT-o} \
+       depfile=sub/conftest.Po tmpdepfile=sub/conftest.TPo \
+       $SHELL ./depcomp $depcc -c -o sub/conftest.${OBJEXT-o} sub/conftest.c \
          >/dev/null 2>conftest.err &&
-       grep conftest.h conftest.Po > /dev/null 2>&1 &&
+       grep sub/conftest.h sub/conftest.Po > /dev/null 2>&1 &&
+       grep sub/conftest.${OBJEXT-o} sub/conftest.Po > /dev/null 2>&1 &&
        ${MAKE-make} -s -f confmf > /dev/null 2>&1; then
       # icc doesn't choke on unknown options, it will just issue warnings
       # (even with -Werror).  So we grep stderr for any message

-- 
Alexandre Duret-Lutz