Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Simon Marchi <simon.marchi@polymtl.ca>
To: Pedro Alves <palves@redhat.com>
Cc: Eli Zaretskii <eliz@gnu.org>,
	Simon Marchi <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 19:38:00 -0000	[thread overview]
Message-ID: <535c5f310c42d9b4e349f5072068fb2a@polymtl.ca> (raw)
In-Reply-To: <0fa3954e-1f8a-f7f8-aad7-d31d45aa981e@redhat.com>

On 2016-11-16 11:56, Pedro Alves wrote:
> # Suppress smart makes who think they know how to automake yacc and 
> flex file
> .y.c:
> .l.c:

I don't understand how that can be useful.  According to the GNU make 
doc:

   Suffix rules with no recipe are also meaningless. They do not remove 
previous
   rules as do pattern rules with no recipe (see Canceling Implicit 
Rules). They
   simply enter the suffix or pair of suffixes concatenated as a target 
in the
   data base.

   Source: 
https://www.gnu.org/software/make/manual/html_node/Suffix-Rules.html

So those two would be meaningless?

> ~~~
> 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).

When looking at the make debug output (make -d), I think it becomes 
obvious:

   http://pastebin.com/raw/cETk9W3v

That's taken without .SUFFIXES or other means to disable implicit rules. 
  For _each_ .c file, make tries to determine if it was generated 
somehow, and you can see the lines which the rules you mentioned would 
suppress.  In our case, most C files are not generated, and those that 
are have an explicit rule.  I don't think we rely on implicit rules.  
Since we don't use them, I think it makes sense to disable then as much 
as possible.  Plus, I can imagine them being a possible source of 
"bugs".  If you happen to have a file called infrun.l by accident, the 
the build will fail and you'll wonder why.

I did some experiments, here's the time it takes to run make in the gdb/ 
directory with nothing to re-build.  The other number is the number of 
lines printed when running make -d.  It gives a rough idea of the amount 
of operations make does.

Note that these results are by changing both gdb/Makefile.in and 
gdb/gdbserver/Makefile.in.  That's fair, since the -r applies 
recursively as well.

                               Baseline: 2.5 seconds, 2306335 lines
                         With .SUFFIXES: 0.7 seconds,  307706 lines
With .SUFFIXES and the other %:: rules: 0.6 seconds,  255386 lines
                 With -r flag (make -r): 0.5 seconds,  160682 lines

So I think it shows that it wouldn't hurt to use ".SUFFIXES =" and the 
other rules from the gcc Makefile.  I couldn't manage to get rid of the 
%.{y,l,w} -> %.c implicit rules though no matter what I tried.  Calling 
make with the -r flag was the only way.  At this point the returns are 
minimal though, so I don't think we should worry about it.



  parent reply	other threads:[~2016-11-16 19:38 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
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 [this message]
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=535c5f310c42d9b4e349f5072068fb2a@polymtl.ca \
    --to=simon.marchi@polymtl.ca \
    --cc=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