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] [PATCH] libxen-3.0 (libxc rewrite)

To: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] libxen-3.0 (libxc rewrite)
From: Jacob Gorm Hansen <jacobg@xxxxxxx>
Date: Tue, 22 Mar 2005 12:12:51 -0800
Delivery-date: Wed, 23 Mar 2005 16:11:47 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <Pine.LNX.4.58.0503221327570.1720@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=xen-devel>
List-help: <mailto:xen-devel-request@lists.sourceforge.net?subject=help>
List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
List-post: <mailto:xen-devel@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=unsubscribe>
References: <423F3BB5.3020600@xxxxxxxxxx> <423F9216.6040806@xxxxxxx> <Pine.LNX.4.58.0503221327570.1720@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
User-agent: Mozilla Thunderbird 1.0 (X11/20050302)
Adam Heath wrote:

I like having a separate build-directory, I still think at non-broken
build tool (i.e. not make) could have done the job and done it better.
The whole .d or .deps approach (pollution of source or build-tree with a
static version of information that could and should be determined at
run-time) is a gross hack, even MS Visual Studio can do better.

runtime?  how do you mean?  The .d is source file deps.

Jam and MS Visual Studio (for example, not that I am advocating the use
of the latter in the scope of this project) both know how to deduce
header-dependencies from the C-source, without littering the tree with
.d files. Since this can be done in virtually zero time, there is no
reason to keep all the .d-files around. Basically that means you no
longer strictly need a separate configure-step, because your source tree
no longer contains any build-specific persistent state, and all your
object files and executables go somewhere if you want them to.

A good build tool will be quick enough that you can just always run it
'just in case', every time you run your program, e.g.

$ jam && ./run

appears to be just as quick as

$ ./run

ps: autoconf itself doesn't give a separate build dir, so don't naively assume

Sorry if I was being naive. There is even less reason to choose autoconf
over Jam then.


This SF.net email is sponsored by: 2005 Windows Mobile Application Contest
Submit applications for Windows Mobile(tm)-based Pocket PCs or Smartphones
for the chance to win $25,000 and application distribution. Enter today at
Xen-devel mailing list