Re: [Xen-devel] [PATCH] libxen-3.0 (libxc rewrite)

[Jacob Gorm Hansen <jacobg@xxxxxxx>]

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
> so.
Sorry if I was being naive. There is even less reason to choose autoconf
over Jam then.

Jacob



-------------------------------------------------------
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
http://ads.osdn.com/?ad_id=6882&alloc_id=15148&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel