|
|
Login/Become a Member! | 28 Comments
|
| | Comments are owned by the poster. We aren't responsible for their content. |
Re: An Interview with Tom Lord of Arch on Versioning Systems
(Score: 1, Insightful)
by Anonymous on Sep 24, 2004 - 11:10 PM
|
Well, it would seem to be the build-level equivalent of separating object from implementation. Surely no bad thing.
I've frequently been uneasy with polluting the source tree with all the instantiation intermediate expression swell. I switched to out-of-tree builds a while ago because of this.
Immediately stopped having a "common" problem that modules compiled to statically link to one set of library interfaces and checked into a revision system immediately failed when checked out to a system with a different version of the library. Of course the module wasn't out of date, it just used a whole slew of incorrect addresses. Most often happened for maintenance on code made prior to an upgrade to the development machines. (The usual solution is to clean up build intermediates. This is different in what detail from only storing source in the repository and forcing a (first) build on a new development pass?)
You can also make your out-of-tree build *look* like an in-tree build by linking to all your sources from the out-of-tree. Then run make on the linked hierarchy. Of course, you have to make a special effort to hoist added files into and remove deleted files from the in-tree. I don't see how one avoids this problem after deciding that the repository will not contain "statically linked to this one version of the library" and "built for this one architecture" intermediates?
My experience is that a couple of hours can be wasted trying to find a bug caused by checking out an incorrect intermediate from a repository, then trying to fix an execution bug in the source that is actually caused by a static linking mismatch or an architecture mismatch in the intermediates. Except on certain projects, this lost time can readily exceed the time to rebuild from clean sources.
|
|
|