public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Patrick Palka <patrick@parcs.ath.cx>
To: Tom Tromey <tromey@redhat.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH] gdb: replace suffix rules with pattern rules
Date: Tue, 14 Jan 2014 01:18:00 -0000	[thread overview]
Message-ID: <CA+C-WL_g0wSEZ4WMSEhJ+qQ7vQFhK6ZL4CdLmS3vcVU3Uax1vQ@mail.gmail.com> (raw)
In-Reply-To: <871u0b3btt.fsf@fleche.redhat.com>

On Mon, Jan 13, 2014 at 2:45 PM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>> "Patrick" == Patrick Palka <patrick@parcs.ath.cx> writes:
>
> Patrick> Suffix rules (e.g. .c.o:) are error-prone and may not interact
> Patrick> well with GNU make's -r/--no-builtin-rules flag.  Replace them
> Patrick> with otherwise-equivalent pattern rules (e.g. %.o: %.c).
>
> Despite appearances, gdb's use of GNU make features is constrained to
> parallel check and, if GNU make is available, dependency tracking.  That
> is, in theory you can do a "one-off" build of gdb using some other make.

I see.  That explains why e.g. static pattern rules are not used either.

> I wouldn't mind requiring GNU make -- gcc has done it for years without
> adverse effects -- but it isn't currently the case.
>
> TBH I am not sure how you'd go about getting this sort of change
> approved.
>
> Patrick> As a result of this change, one can now successfully build gdb/ with
> Patrick> make's -r flag which improves build time by a bit.
>
> There's a zillion other directories to cope with in the tree.
> Does make -r work in all of them except gdb?
> If so, how?

Not all.  The directories whose makefiles are generated by automake
work under make -r and so do the ones that don't use suffix rules at
all. The ones generated by
automake work because automake makes sure to explicitly populate the
.SUFFIXES target with the relevant file extensions.  The gdb/ makefile
doesn't work
under make -r essentially because it relies on a ".c.o:" suffix rule
but the file extensions .c and .o are not in .SUFFIXES.  (So, a
portable variant of the above patch would be to make sure to add .c
and .o into the .SUFFIXES target, leaving the suffix rules in place.)
Likewise for one or two other makefiles in the tree, suchas the one
under readline/.

I was not aware of the concern about portability.  I'll repost a
portable version of the patch once I submit my copyright assignment.

  reply	other threads:[~2014-01-14  1:18 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-12 21:56 Patrick Palka
2014-01-13 19:45 ` Tom Tromey
2014-01-14  1:18   ` Patrick Palka [this message]
2014-01-14  2:55     ` Tom Tromey

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=CA+C-WL_g0wSEZ4WMSEhJ+qQ7vQFhK6ZL4CdLmS3vcVU3Uax1vQ@mail.gmail.com \
    --to=patrick@parcs.ath.cx \
    --cc=gdb-patches@sourceware.org \
    --cc=tromey@redhat.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).