From: Ian Campbell <ian.campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Cc: ian.jackson@eu.citrix.com, xen-devel@lists.xen.org
Subject: Re: [PATCH v2 6/7] build system: stubdom targets now depends on mini-os target
Date: Tue, 24 Feb 2015 17:26:07 +0000 [thread overview]
Message-ID: <1424798767.20243.21.camel@citrix.com> (raw)
In-Reply-To: <20150224171220.GO20083@zion.uk.xensource.com>
On Tue, 2015-02-24 at 17:12 +0000, Wei Liu wrote:
> On Tue, Feb 24, 2015 at 05:01:26PM +0000, Ian Campbell wrote:
> > On Tue, 2015-02-24 at 16:52 +0000, Wei Liu wrote:
> > > On Tue, Feb 24, 2015 at 04:33:17PM +0000, Ian Campbell wrote:
> > > > On Fri, 2015-02-20 at 11:17 +0000, Wei Liu wrote:
> > > > > @@ -161,7 +163,7 @@ clean-tools:
> > > > > $(MAKE) -C tools clean
> > > > >
> > > > > .PHONY: clean-stubdom
> > > > > -clean-stubdom:
> > > > > +clean-stubdom: mini-os-dir
> > > > > $(MAKE) -C stubdom crossclean
> > > > > ifeq (x86_64,$(XEN_TARGET_ARCH))
> > > > > XEN_TARGET_ARCH=x86_32 $(MAKE) -C stubdom crossclean
> > > > > @@ -187,11 +189,12 @@ distclean-tools:
> > > > > $(MAKE) -C tools distclean
> > > > >
> > > > > .PHONY: distclean-stubdom
> > > > > -distclean-stubdom:
> > > > > +distclean-stubdom: mini-os-dir
> > > >
> > > > These two are a bit odd, since they will force a clone in order to clean
> > > > (and in the distclean case immediately discard again).
> > > >
> > >
> > > That's because stubdom's distclean is quite broken, it just won't work
> > > without mini-os.
> >
> > If the mini-os dir is not present then I don't think there is any need
> > to distclean the stubdom, is there? How would anything be present?
> >
>
> If user builds stubdom then deletes mini-os then wants to clean
> studom.
I think users who randomly delete things can be expected to cope with
randomly cleaning other stuff too ;-)
>
> If we don't have that dependence, we just print
>
> Please run `make mini-os-dir' in top-level directory
>
> due to a check in stubdom's Makefile. I think this is acceptable too.
That's better than cloning then removing it everytime someone runs
distclean, for sure.
I'd prefer something saying "not cleaning because" but I suppose the
above is from a generic catch-all rule not a *clean specific one.
> > > > The way we handle this with e.g. qemu is to have
> > > > subdir-clean-qemu-xen-traditional-dir:
> > > > set -e; if test -d qemu-xen-traditional-dir/.; then \
> > > > $(MAKE) -C qemu-xen-traditional-dir clean; \
> > > > fi
> > > >
> > > > so I think you want a pair of {clean,distclean}-mini-os-dir rules which
> > > > recurse iff the dir exists.
> > > >
> > >
> > > No, we don't actually need to enter mini-os dir and make clean /
> > > distclean when doing clean and distclean of stubdom.
> >
> > Didn't you just contradict what you said further above?
> >
>
> I was thinking all those objects are not placed inside min-os's dir so
> there is nothing to clean inside mini-os's directory
>
> However, stubdom does have
> $(MAKE) DESTDIR= -C $(MINI_OS) clean
>
> So there is no need for a separate subdir-clean-mini-os-dir.
I see. What I was trying to say (and did badly, and then misunderstood
your response) was that the stubdom *clean should check for mini-os-dir
(which is different to the qemu case, I admit).
i.e. what I really was thinking of was:
subdir-clean-stubdom:
set -e; if test -d mini-os-dir/.; then \
$(MAKE) -C stubdom clean; \
else
echo "Not running clean in stubdom, no mini-os-dir.";\
echo "run `make mini-os-dir' in top-level before cleaning stubdom" ;\
fi
(similar for distclean)
> We can also delete that line. But I would avoid touching stubdom's
> Makefile if not necessary.
>
> Wei.
next prev parent reply other threads:[~2015-02-24 17:26 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-20 11:17 [PATCH v2 0/7] Split off mini-os to a separate tree Wei Liu
2015-02-20 11:17 ` [PATCH v2 1/7] stubdom: fix "make build" Wei Liu
2015-02-20 11:17 ` [PATCH v2 2/7] Makefile: refactor build/clean/distclean targets Wei Liu
2015-02-20 11:17 ` [PATCH v2 3/7] stubdom: don't look for mini-os source file during configure Wei Liu
2015-02-24 16:25 ` Ian Campbell
2015-02-20 11:17 ` [PATCH v2 4/7] git-checkout.sh: use "mkdir -p" Wei Liu
2015-02-20 11:17 ` [PATCH v2 5/7] Mini-OS: standalone build Wei Liu
2015-02-24 16:27 ` Ian Campbell
2015-02-24 16:33 ` Wei Liu
2015-02-24 19:39 ` Samuel Thibault
2015-02-25 9:53 ` Ian Campbell
2015-02-25 9:56 ` Samuel Thibault
2015-02-20 11:17 ` [PATCH v2 6/7] build system: stubdom targets now depends on mini-os target Wei Liu
2015-02-24 16:33 ` Ian Campbell
2015-02-24 16:52 ` Wei Liu
2015-02-24 17:01 ` Ian Campbell
2015-02-24 17:12 ` Wei Liu
2015-02-24 17:22 ` Wei Liu
2015-02-24 17:26 ` Ian Campbell
2015-02-24 17:26 ` Ian Campbell [this message]
2015-02-20 11:17 ` [PATCH v2 7/7] Remove in-tree mini-os directory Wei Liu
2015-02-24 16:36 ` [PATCH v2 0/7] Split off mini-os to a separate tree Ian Campbell
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=1424798767.20243.21.camel@citrix.com \
--to=ian.campbell@citrix.com \
--cc=ian.jackson@eu.citrix.com \
--cc=wei.liu2@citrix.com \
--cc=xen-devel@lists.xen.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.