Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Pedro Alves <palves@redhat.com>
Cc: simon.marchi@ericsson.com, gdb-patches@sourceware.org
Subject: Re: [PATCH 3/4] Makefile: Replace old suffix rules with pattern rules
Date: Wed, 16 Nov 2016 17:14:00 -0000	[thread overview]
Message-ID: <83k2c3fitl.fsf@gnu.org> (raw)
In-Reply-To: <0fa3954e-1f8a-f7f8-aad7-d31d45aa981e@redhat.com> (message from	Pedro Alves on Wed, 16 Nov 2016 16:56:02 +0000)

> Cc: gdb-patches@sourceware.org
> From: Pedro Alves <palves@redhat.com>
> Date: Wed, 16 Nov 2016 16:56:02 +0000
> 
> Given the shared ancestry, and the fact that GCC nowadays requires
> GNU make, I think it may be worth it to take a look at what
> does GCC's Makefile.in do.
> 
> In this case, it has:
> 
> ~~~
> # Suppress smart makes who think they know how to automake yacc and flex file
> .y.c:
> .l.c:
> 
> # The only suffixes we want for implicit rules are .c and .o, so clear
> # the list and add them.  This speeds up GNU Make, and allows -r to work.
> # For i18n support, we also need .gmo, .po, .pox.
> # This must come before the language makefile fragments to allow them to
> # add suffixes and rules of their own.
> .SUFFIXES:
> .SUFFIXES: .c .cc .o .po .pox .gmo
> ~~~
> 
> I don't know why they still add some suffixes instead of relying
> on the pattern rules.  Might just be legacy.

No, it's because of the built-in rules.  They are by default
considered no matter which pattern rules you have in the Makefile,
because theoretically each .c file can be built from some other file
in any number of ways.

> This doesn't get rid of all the implicit rules in GNU make, however,
> because some default rules are pattern rules which are not affected by
> the .SUFFIXES special target.
> 
> To get rid of all implicit rules in GNU make you have to either invoke
> make with the -r option [...], or else add this to your makefile:
> 
>   .SUFFIXES:
>   %:: %,v
>   %:: RCS/%,v
>   %:: RCS/%
>   %:: s.%
>   %:: SCCS/s.%
> ~~~
> 
> I'd be curious if this makes any difference in a "make" invocation
> that ends up building nothing (because all targets are already
> up to date).

It might produce a significant difference, but of course the
interesting case is when a small number of files need to be
recompiled.


  reply	other threads:[~2016-11-16 17:14 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-16 16:11 [PATCH 0/4] Require GNU make Simon Marchi
2016-11-16 16:10 ` [PATCH 4/4] Makefile: Replace explicit subdir rules with pattern rules Simon Marchi
2016-11-16 17:11   ` Pedro Alves
2016-11-16 16:12 ` [PATCH 2/4] Remove code that checks for GNU/non-GNU make Simon Marchi
2016-11-16 16:32   ` Eli Zaretskii
2016-11-16 16:39     ` Andreas Schwab
2016-11-16 17:12       ` Pedro Alves
2016-11-16 17:12       ` Simon Marchi
2016-11-16 17:09   ` Pedro Alves
2016-11-16 16:12 ` [PATCH 1/4] Document new hard requirement on GNU make Simon Marchi
2016-11-16 16:29   ` Eli Zaretskii
2016-11-16 17:05     ` Simon Marchi
2016-11-16 17:23       ` Eli Zaretskii
2016-11-16 22:05         ` Simon Marchi
2016-11-16 23:34           ` Pedro Alves
2016-11-17 12:39             ` Pedro Alves
2016-11-17 13:39               ` Simon Marchi
2016-11-17 16:10                 ` Eli Zaretskii
2016-11-17  3:35           ` Eli Zaretskii
2016-11-17 10:06             ` Jonas Maebe
2016-11-17 12:43               ` Pedro Alves
2016-11-16 16:12 ` [PATCH 3/4] Makefile: Replace old suffix rules with pattern rules Simon Marchi
2016-11-16 16:35   ` Eli Zaretskii
2016-11-16 16:56     ` Pedro Alves
2016-11-16 17:14       ` Eli Zaretskii [this message]
2016-11-16 17:32         ` Pedro Alves
2016-11-16 17:49           ` Eli Zaretskii
2016-11-16 17:58             ` Pedro Alves
2016-11-16 19:38       ` Simon Marchi
2016-11-16 19:58         ` Pedro Alves
2016-11-16 20:18           ` Simon Marchi
2016-11-16 19:11   ` Pedro Alves
2016-11-17 16:52     ` Simon Marchi
2016-11-17 16:57       ` Pedro Alves
2016-11-17 17:05 ` [PATCH 0/4] Require GNU make Simon Marchi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83k2c3fitl.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=gdb-patches@sourceware.org \
    --cc=palves@redhat.com \
    --cc=simon.marchi@ericsson.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox