Recent Features
| |||||||||||||
GNU Guix launchesGNU Guix launchesPosted Nov 26, 2012 7:09 UTC (Mon) by oever (subscriber, #987)In reply to: GNU Guix launches by jreiser Parent article: GNU Guix launches
That sounds like bliss! It would be great if we could have a way to do this today. It would really help with security and debugging and could help reduce compile times. If everybody in a development team is using the same tool chain, determined by the checksum for the toolchain, then many of the compiled files could be shared among the team.
It would allow build systems to look at checksum of the output and input files to see if a file is up to date or needs rebuilding. This is much more reliable than using mtimes. A log would need to be kept of which inputs give which outputs, but that seems worth it.
(Log in to post comments)
GNU Guix launches Posted Nov 26, 2012 10:33 UTC (Mon) by rossburton (subscriber, #7254) [Link]
The Yocto Project does something like this to speed up distribution compiles, by checksumming all variables, dependencies, and sources. If the hash exists in the cache, a pre-compiled package is extract and used.
GNU Guix launches Posted Nov 26, 2012 12:55 UTC (Mon) by NAR (subscriber, #1313) [Link]
In a previous project a couple of guys did just that. C++ compiling on ridiculously slow Sparc workstations was not fun, so checksums were made from the sources and object files were reused. If I remember it correctly, the speed gained was not that much as we hoped for and sometimes strange things happened - but this was 10 years ago and my memories could be wrong here. Faster CPU and disk was the real solution.
GNU Guix launches Posted Nov 26, 2012 14:01 UTC (Mon) by vonbrand (subscriber, #4458) [Link] ccache to the rescue... almost invisible, works like a charm (only got bitten when crashes left empty .o files lying around, which ccache deemed correct...)
GNU Guix launches Posted Nov 26, 2012 13:59 UTC (Mon) by vonbrand (subscriber, #4458) [Link] I'm sorry, but if you have a "development team" which shares object files, having all of them using the exact same tools should be a cinch, just have each one run the same version of your favorite distribution (modulo "recompile all worlds" each time GCC/coreutils/... version gets bumped). Not really needed most of the time, I re-make some projects I follow with updates, and that doesn't require to recompile everything even if gcc changes. Only rarely do I have to clean beforehand. Even so, compile timestamps get embedded in object (and other) files, perhaps even host names and assorted other trivia. Just take a look at the lengths GCC's build goes to check that stage 2 and 3 builds are the same.
GNU Guix launches Posted Nov 26, 2012 20:02 UTC (Mon) by zooko (subscriber, #2589) [Link]
The Vesta configuration management tool accomplishes some of what you want by requiring all of your build tools and, in general, everything that could affect the build output, to be served by an NFS local mount, so that Vesta can keep track of all the files that the build process looked at while building. Vesta then makes a copy of the current version of each of those files in its revision control history so that you can rebuild the exact same build output in future years. :-)
(Caveat: obviously there are always more ways that this can go wrong, like your new kernel has a different set of bugs than your old kernel, that affect your compiler's behavior. But still, Vesta's approach sounded good to me.)
https://en.wikipedia.org/wiki/Vesta_%28Software_configura...
Back to the direct topic: I'm excited about Guix! Because I love the ideas of determinism, transactional upgrade and rollback, and the other related features. Nix is also associated with another Very Good Idea — your autobuild system should also run the unit tests automatically, unifying "Continuous Integration" (like Buildbot, Jenkins, etc.) with autobuilder.
|
|||||||||||||