This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch] Makefile dependencies for included .md files
- From: Jim Wilson <wilson at specifixinc dot com>
- To: Paul Brook <paul at codesourcery dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Mon, 12 Jan 2004 19:23:35 -0800
- Subject: Re: [patch] Makefile dependencies for included .md files
- References: <200401042041.33133.paul@codesourcery.com>
Paul Brook wrote:
I've noticed that the gcc Makefiles don't include dependencies for .md files
which are included for the main file. This means that changes to eg. config/
i386/athlon.md aren't noticed unless you also touch config/i386/i386.md.
There is an "echo $md_base" that doesn't seem to do anything.
I'm not sure about the sed command that removes newlines via a loop. Do
we have anything like this anywhere else?
I looked at the code that implements the rtl include operator in
gensupport.c. It has support for absolute pathnames, and support for -I
options to specify alternate search directories. Your patch for
generating dependencies does not. So there is a mismatch of features
here. There are no current md files that rely on these features, but
eventually there will be, or someone will use them for testing
development work, and then we will have a problem. It would be nicer if
we got this right from the start.
If we want to automate this, I think we need a gen* program to generate
the dependency list for us, in order to ensure that the dependency list
matches the list of files that the gen* programs will actually use. So
this would be like using a -M preprocessor option. This is a bit more
work, and I don't think we have anything like this already, at least not
in the gcc directory.
An alternative would be to maintain manual lists of extra md files
somewhere. Perhaps in the config.gcc file. This is usually what we do.
For instance, it is what we do for for header files included by C files.
Another alternative is to remove the extra rtl include operator features
that we aren't using, so that it is simpler to generate the
dependencies. It is harder to make a case for this though.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com