Re: GNU make bugs reported in comp.unix.solaris

[Paul D. Smith]

%% Paul Eggert <address@hidden> writes:

  >>> - GNU make does not "make" >included<  make rule files
  >>> and complains about nonexistent files

I don't understand the first one here; make _does_ make included make
rule files.  Perhaps he means it includes them before trying to make
them; this is true.

The second issue (the error messages make prints) is one Joerg has had
with GNU make for a while.  There is a bug reported on it.

However, while there is no question that the messages are annoying and
deceptive, nevertheless make _does_ behave correctly and rebuild those
files.  It's on the "to fix" list, but as the behavior is ultimately
correct and the fix is not a no-brainer (marking the included file as
non-existent rather than generating the message is trivial; what's not
so trivial is getting make to then generate the proper message later on
when it really knows that the file can't be created and this is an
error), it hasn't yet hit the top of that list.

Also note that the dependency generation method being used by Joerg is
deprecated; it just doesn't work well at all except for the most trivial
cases.  There is a much better method, invented by Tom Tromey and used
by automake, which avoids (as far as I can tell) all these issues and is
more accurate and efficient to boot.  There is no need to try to make
included files before they're included, and no mistaken error messages
are printed; I've pointed this out to Joerg in the past.

See:

  http://www.paulandlesley.org/gmake/autodep.html

  >>> - GNU make then "makes" these files in the reverse order
  >>> and even includes them in reverse (wrong) order.

Make does rebuild makefiles in the reverse order from which they're
included.  It could be argued that this is a bug, but note I find it
very difficult to imagine a correct makefile where this makes any
difference; recall that even included makefiles use the normal make
prerequisite walking algorithms.  At any rate, it should be simple to
fix.

However, make definitely includes them in the correct order!

Consider:

  $ cat makefile

  include x.mk y.mk
  x.mk y.mk: ; echo '$$(warning $@)' > $@
  all: ; @echo foo

  $ make
  makefile:1: x.mk: No such file or directory
  makefile:1: y.mk: No such file or directory
  echo '$(warning y.mk)' > y.mk
  echo '$(warning x.mk)' > x.mk
  x.mk:1: x.mk
  y.mk:1: y.mk
  foo

Here we see the issue with the incorrect message printed, then it
invokes the builds in the reverse order, _but_ the includes _are_
processed in the correct order, not the reverse order.

I would consider this a very serious bug if includes were handled
backwards!  I don't see how this can be so, though, since make simply
re-execs and runs the same code again.

  pe> Note that the main purpose for doing this is to create dependency
  pe> rules (*).  GNU make re-execs itself in some cases toget around
  pe> the problem but this is not needed

Again, this entire method of generating dependency rules is simply not
the right one.  Change to use the right method, and these problems will
go away.

Another way to solve the problems, I realize, is to change make to avoid
them.  However, make has worked the way it does for many, many years and
it's not clear to me at all that the best way to resolve Joerg's issues
is to fundamentally change the way it handles this situation.  I'd
prefer to see people simply use better methods (obviously, I'm biased
since I'm the maintainer :).

I do understand that this is just a common example and there could be
other situations with these same problems where they are not so easy to
resolve.

  >>> - As GNU make copied the Sun idea of Pattern Matching
  >>> Default Rules, GNU make will not honor the evaluation
  >>> rules for precedence of these Rules.
  >>> The result is to use the wrong default rules.
  >> 
  >> Again, do you have an example, or a pointer to one?

  pe> $(ARCHDIR)/%.o:         %.c
  pe>                         $(CC) $(CFLAGS) $(CPPFLAGS) -c -o $@ $<

  pe> $(ARCHDIR)/%.o:         %.s
  pe>                         $(CAS) $(ASLAGS) $(CPPFLAGS) -o $@ $<

  pe> Will first look for a .c file and then for a .s file.  If you put
  pe> each rule into a separate include rule file and the order of
  pe> include is reversed, then the order of precedence is not as
  pe> intended.

Certainly _if_ the order of include is reversed, then the order is not
as intended.  However, the order of include is _not_ reversed, or I
cannot come up with a situation where it is so:

  $ cat makefile
  .SUFFIXES:
  .SUFFIXES: .mk
  include y.mk z.mk
  all: foo.x
  y.mk z.mk : ; echo '%.x : %.$*; cp $$< $$@' > $@

  $ rm y.mk z.mk && touch foo.y foo.z && make
  makefile:3: y.mk: No such file or directory
  makefile:3: z.mk: No such file or directory
  echo '%.x : %.z; cp $< $@' > z.mk
  echo '%.x : %.y; cp $< $@' > y.mk
  cp foo.y foo.x

Note that the pattern rule chosen is the one from the _first_ included
file, y.mk.  If you reverse the include order:

  include z.mk y.mk

then it will choose the z.mk rule.

I don't see the problem; please submit a bug with an example if you know
of one.

  pe> (*) The gcc -MD option in principle could help but it is currently
  pe>   not usable. 

Joerg is correct that GCC's -MD is not as functional as necessary, but
he's mistaken in that this means this method cannot be used: the GNU C
preprocessor _does_ have the functionality he wants, it's just not
available as an option directly through the GCC interface

Recall GCC is but a front-end to the various programs that do the real
work: those programs have a richer command-line interface than is
available directly through the GCC front-end.  But, that doesn't mean
you can't access them from GCC.  If you check my page above you'll find
that you can use the -Wp option to invoke the preprocessor with the
proper arguments:

 > You can do this in some older versions of GCC by using an environment
 > variable. You can also specify an alternate filename for the output
 > file by passing options through GCC directly to the preprocessor,
 > with an option sequence, something like this: -Wp,-MD,$*.xx. This is
 > especially useful if you want the output dependency files in a
 > different directory. See the manual for your compiler and/or your
 > preprocessor for more information.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <address@hidden>          Find some GNU make tips at:
 http://www.gnu.org                      http://www.paulandlesley.org/gmake/
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist