All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jan Beulich" <JBeulich@suse.com>
To: Juergen Gross <jgross@suse.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: Automatic dependencies are out of sync
Date: Thu, 06 Sep 2018 04:26:59 -0600	[thread overview]
Message-ID: <5B9100F302000078001E5E17@prv1-mh.provo.novell.com> (raw)
In-Reply-To: <02463da8-eeff-f254-b8c2-5c1e5b96ab53@suse.com>

>>> On 06.09.18 at 10:27, <jgross@suse.com> wrote:
> On 06/09/18 10:10, Jan Beulich wrote:
>>>>> On 06.09.18 at 09:34, <jgross@suse.com> wrote:
>>> I've setup a little example Makefile solving the problem (just to show
>>> the correct dependencies, needs to be adapted for naming the .d and .d2
>>> files and how to build the .d2):
>>>
>>> -->8 snip here 8<--
>>>
>>> DEPS := tst.d2
>>>
>>> all: tst $(DEPS)
>> 
>> -include $(DEPS) already ought to have the effect of such a dependency,
>> since all makefiles are checked for rules of how to re-make them.
> 
> Obviously this isn't the case. Otherwise there would be .d2 files more
> common after doing a make.

Well, be this (mis?)behavior is what needs explaining first.

>>> %.o %.d: %.c
>>>         gcc -MMD -o $(patsubst %.c,%.o,$<) -c $<
>> 
>> Doesn't this result in gcc to be invoked twice, perhaps resulting in
>> corrupt .o and/or .d? I think %.d wants to depend on %.o, without
>> a command.
> 
> No, that's perfectly fine. make will invoke the command only once, its
> just not clear for which target (that's the reason I need to use the
> $(patsubst %.c,%.o,$<) instead of $@, which might be the .o _or_ the .d
> file).
> 
> From the make docs:
> 
>   Pattern rules may have more than one target. Unlike normal rules, this
>   does not act as many different rules with the same prerequisites and
>   recipe. If a pattern rule has multiple targets, make knows that the
>   rule’s recipe is responsible for making all of the targets. The recipe
>   is executed only once to make all the targets.

Oh, right. But then there's no need to play games - just use $*.

>>> %: %.o
>>>         gcc $< -o $@
>>>
>>> -include $(DEPS)
>>>
>>> -->8 snip here 8<--
>>>
>>> So the basic ideas are:
>>>
>>> - add a rule for constructing the .d files
>>> - let the build depend on the .d2 files
>> 
>> IOW I wonder whether this really is any different from what we
>> do now (minus bugs/quirks in make itself, of course). And from this
>> as well as your original mail I still don't understand what's actually
>> broken with the current approach.
> 
> The main problem is that the .d2 files used for determining which object
> files need to be (re-)built are based on the build before the last one.
> I'm not sure this is always the case, but at least when starting with a
> clean tree I need two invocations of "make" to get all .d2 files built.

But that's correct: They're not needed _until_ a rebuild happens.
And by way of make's rebuilding of makefiles (if there are suitable
rules) they should appear _before_ any .o gets rebuilt, and even
before make evaluates which ones need rebuilding.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

  reply	other threads:[~2018-09-06 10:27 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-05 14:05 Automatic dependencies are out of sync Juergen Gross
2018-09-06  7:34 ` Juergen Gross
2018-09-06  8:10   ` Jan Beulich
     [not found]   ` <5B90E0DE02000078001E5D5A@suse.com>
2018-09-06  8:27     ` Juergen Gross
2018-09-06 10:26       ` Jan Beulich [this message]
     [not found]     ` <02463da8-eeff-f254-b8c2-5c1e?= =?UTF-8?Q?5b96ab53@suse.com>
2018-09-06  8:39       ` Andrew Cooper
     [not found]     ` <02463da8-eeff-f?= =?UTF-8?Q?254-b8c2-5c1e5b96ab53@suse.com>
     [not found]       ` <5B9100F302000078001E5E17@suse.co?= =?UTF-8?Q?m>
2018-09-06 12:21         ` Juergen Gross

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=5B9100F302000078001E5E17@prv1-mh.provo.novell.com \
    --to=jbeulich@suse.com \
    --cc=Ian.Jackson@eu.citrix.com \
    --cc=jgross@suse.com \
    --cc=xen-devel@lists.xenproject.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.