This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] xen-unstable: build fails

To: Juergen Gross <juergen.gross@xxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] xen-unstable: build fails
From: Keir Fraser <keir.xen@xxxxxxxxx>
Date: Thu, 17 Mar 2011 08:11:57 +0000
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 17 Mar 2011 01:13:06 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:user-agent:date:subject:from:to:cc:message-id :thread-topic:thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=guDGLzKcF7/HhsjBVenwPzpHPYekD7MWo6OqRAlKpAo=; b=jBSLJvrwym+hdPPZ8sKfk0L4NAukJu93VHyAUtOgtmnTNNs9+0PqqC2hrG8yHqMXDe eXE/jx0eYJHom/nForUDHPnz32hUk/fLWJ9TsOiQByjnwleLCZXvG7oNAwEP3nwNRT5p o/88cHdpc7BqY5FxW1c9ZLyyf8qJ0P8PyIk20=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; b=lJF0zUGzmi8lyJ8ELfX4WtvRTB0YZjfQnjsbb6FiFiXX6sWEJSKMiRUlDzVv5bsLnO 530H9cFOEUftGF5yTDKHmFUj6rU4kqKKsa6RyFUcn4IupDH6y59psCj6414YW27/XhVz dfbd03lUzv/fHq8FYE4Npp5AB16sFow3q996Q=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4D81A1B7.2060306@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcvkevuwpuYxLgoI20m2BBAbRxIj+A==
Thread-topic: [Xen-devel] xen-unstable: build fails
User-agent: Microsoft-Entourage/
On 17/03/2011 05:52, "Juergen Gross" <juergen.gross@xxxxxxxxxxxxxx> wrote:

> The reason is clear: XEN_ROOT is set to a *relative* path. And when make is
> including a Makefile, it switches the working directory to the directory of
> the included Makefile. Including another Makefile via XEN_ROOT then is the
> problem...

Well it's not clear to me. In my tests, including another Makefile does not
change the working directory, only recursive make with -C specified does
that. That seems logical -- pulling in standard rules containing wildcard
globs would otherwise have unpredictable results, if the wildcards were
evaluated in the directory of the included Makefile.

In your case, if Config.mk was getting run with incorrect relative XEN_ROOT,
how would the earlier include lines in that file work? You are getting an
error on '-include $(XEN_ROOT)/.config', but there are earlier (and
unconditional!) include lines in Config.mk that also reference XEN_ROOT. I
suppose they must be working.

So I think something is weird in your environment, or your make is broken.
However in this one specific failure case I can avoid redefining XEN_ROOT
outside xen/Makefile, since all hypervisor builds start at that Makefile. So
you can see whether c/s 23048 in xen-unstable staging fixes your build. I
applied it as it happens to be a teeny tiny cleanup as well.

 -- Keir

>>> The reason seems to be a directory /root/.config which isn't present on my
>>> other machines.
>> We shouldn't be referring outside the repository. AFAICS the above logging
>> doesn't indicate that we are. I don't understand why you are getting that
>> error. I haven't been able to reproduce it.
> I have :-(
>>> fails in a similar way. Many Makefiles seem to contain lines like:
>>> XEN_ROOT=../..
>>> which is a really bad idea in my opinion. XEN_ROOT should only be set, if it
>>> is not yet defined.
>> Why? It's private to our build system. We don't want the user screwing with
>> it. I also don't see why relative paths within our repository should be
>> avoided, as you try to do in your alternative formulation.
> You have to avoid relative paths in make variables used in different directory
> levels.
> Juergen

Xen-devel mailing list