| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] [PATCH] libxen-3.0 (libxc rewrite)
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
|
|
|
| |
|
Home