[PATCH] - Fix bogus dependency in Makefile.in

[Zack Weinberg]

As the person who introduced some of the constructs that don't work, I
think I'll chime in here...

On Mon, Jul 10, 2000 at 10:00:50PM +0200, Marc Espie wrote:
> 
> The part that doesn't make sense is that it doesn't work, namely
> libgcc.mk does not have proper dependencies.
>
> The directory build forces a rebuild of all .o files.  It's possible
> that you are depending on a gnu-make feature, that is definitely not
> in other posix makes. Since the directory target is always out of
> date, it gets rebuilt. It doesn't matter that the date does not
> change.  It got rebuilt, so all object files get rebuilt as well.

The object files have to depend on their directories, otherwise in a
parallel build you might have one of the compiles try to create
dir/foo.o before dir exists.

This is the offending rule:

stmp-dirs: force
        for d in libgcc; do \
          if [ -d $$d ]; then true; else mkdir $$d; fi \
        done
        if [ -f stmp-dirs ]; then true; else touch stmp-dirs; fi

It seems to me that should be written

stmp-dirs:
	if [ -f stmp-dirs ]; then :; else	\
	  for d in libgcc; do			\
	    if [ -d $$d ]; then :; else		\
	      rm -f $$d;			\
	      mkdir $$d;			\
            fi;					\
	  done;					\
	  touch stmp-dirs;			\
	fi 

(where 'for d in libgcc' might be a loop over multilib subdirectories;
it's not vacuous.)  We don't need to force the rule, and we should do
nothing at all if stmp-dirs exists.  Will that work properly with your
make?

> The other part that doesn't make sense is that you don't say what you mean.
> ${LANGUAGES} does not mean anything as a target. If you want to force 
> something, use force, not a substitute that is utterly confusing and looks
> like a bug.

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.

Note that a number of these problems would disappear if libgcc.mk and
libgcc.a were explicitly rebuilt in each stage of bootstrap.  I do not
know why this isn't done now.  I can think of a number of other ways
to handle the problem, but they all involve drastic changes to the
build process.  Which I would be delighted to do, but I don't have
time right now.

zw