This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] - Fix bogus dependency in Makefile.in
One thing which is glaringly obvious to me is this.
Assuming your reasoning is correct (but read the end of this message),
there should be a comment in the Makefile that explains what is going on.
This is sneaky, and easy to lose track of.
Explaining what $(LANGUAGES) does here should be mandatory. How can I expect
to find out about this otherwise ? (wadding through the mailing-list archives
is not an option, and the ChangeLog isn't either)
On Mon, Jul 10, 2000 at 04:23:46PM -0700, Zack Weinberg wrote:
>
> Here you're talking about this bit, right?
>
> libgcc.a: $(GCC_PASSES) $(LANGUAGES) [other stuff]
> [gargantuan recursive make command]
>
> The use of $(LANGUAGES) is quite deliberate and is the *only* way I
> could find - after some hours of searching - to get the necessary
> effect. It is rather subtle - watch carefully:
>
> In a build with C++ enabled at configure time, the final libgcc.a
> contains object files that are built by cc1plus; and in general it
> might contain objects built by any front end. (I do not like this
> policy, but we're stuck with it. At the moment C++ is the only
> language that needs to add stuff to libgcc.a.) We have to have those
> compilers available when libgcc.a is built. That is a true dependency
> which must be expressed to Make.
>
> In stage1 we must not build any compiler other than cc1, because the
> other front ends are allowed to contain code that won't compile with a
> K+R compiler. (I don't like this policy either.) But we have to
> build libgcc.a. We avoid including the specific object modules that
> need the C++ compiler, by Byzantine contortions, but that doesn't get
> rid of the dependency of libgcc.a on the C++ compiler.
>
> The upshot is that the dependency of libgcc.a on C++ has to be
> expressed such that it is only present after stage 1. The *only* way
> to do that, under the current infrastructure, is to have libgcc.a
> depend on $(LANGUAGES). And it works - for me, for HJ who spotted the
> problem in the first place, for rth who has an 8-way alpha to run
> parallel builds on. But we're all using gnumake. I am quite
> interested to know what exactly your make doesn't like about this
> construction.
Well, what you are writing is a dependency on ${LANGUAGES], which happens
to contain c++... which happens to be an executable.
This also happens to contain (possibly) chill, java, objective-c, and
whatnot, which are usually NOT executable programs.
What this means is that libgcc.mk is re-triggered at each stage, for almost
all builds.
This does not gain you much from simply putting a force dependency.
In fact, the only gain is when you build C and C++, not the other languages.
This looks more like a bug to me... or at least a fairly fragile feature
that is not worth it.