preprocessor/6521: -MG creates dependency with wrong path
Robert Spier
rspier@pobox.com
Tue May 7 23:12:00 GMT 2002
>> Why is this the intended behavior? It doesn't make much sense to me.
>
>It's intended because it's what the comment in the code says and
>does.
Ok.. But why? Beyond it's existence, it doesn't make any sense to
me.
>I'd welcome a patch to do something more sensible. You can wait for me
>to look at it, but it's pretty near the bottom of my to-do list.
The only sensible patch I can think of is to remove this odd
functionality entirely.
The below patch unifies handling for system and non-system include
files and removes the special case. It only affects -MG, and brings
it in line with the documentation:
-MG When used with -M or -MM, -MG says to treat missing
header files as generated files and assume they live
in the same directory as the source file. It sup
presses preprocessed output, as a missing header file
is ordinarily an error.
The patch is against the 20020506 snapshot.
Thanks!
-R
===================================================================
RCS file: gcc/cppfiles.c,v
retrieving revision 1.1
diff -u -r1.1 gcc/cppfiles.c
--- gcc/cppfiles.c 2002-05-07 22:33:13-07 1.1
+++ gcc/cppfiles.c 2002-05-07 22:35:48-07
@@ -658,28 +658,8 @@
if (CPP_OPTION (pfile, print_deps_missing_files) && print_dep)
{
- if (!angle_brackets || IS_ABSOLUTE_PATHNAME (fname))
+ /* Assume missing headers are in the current directory */
deps_add_dep (pfile->deps, fname);
- else
- {
- /* If requested as a system header, assume it belongs in
- the first system header directory. */
- struct search_path *ptr = CPP_OPTION (pfile, bracket_include);
- char *p;
- int len = 0, fname_len = strlen (fname);
-
- if (ptr)
- len = ptr->len;
-
- p = (char *) alloca (len + fname_len + 2);
- if (len)
- {
- memcpy (p, ptr->name, len);
- p[len++] = '/';
- }
- memcpy (p + len, fname, fname_len + 1);
- deps_add_dep (pfile->deps, p);
- }
}
/* If -M was specified, then don't count this as an error, because
we can still produce correct output. Otherwise, we can't produce
More information about the Gcc-bugs
mailing list