On Thu, Jan 21, 2010 at 02:52, Michael Schuster <Michael.Schuster at sun.com> wrote: > Stefan Teleman wrote: >> >> On Wed, Jan 20, 2010 at 17:41, Ben Taylor <bentaylor.solx86 at gmail.com> >> wrote: >>> >>> Does anyone see any value in tweaking the infrastructure such that: >>> >>> WDYT? >> >> No, I see no value whatsoever in this idea. >> >> Can you provide a single other example in which the build system for a >> particular piece of software relies on a specific and non-portable >> filesystem feature ? > > I think you're being a bit harsh here, Stefan - as I read Ben's suggestion, > he's thinking of an optional feature that could speed up the > write-build-test cycle ... ie, not tying anything to zfs, just optimising > for zfs *if* it's in use.
Really ? Harsh ? I really don't see how speeding up the uncompression of tarballs helps with development. It doesn't. It perhaps provides an insignificant speedup of full builds, and not much more. Speeding up development would involve speeding up the discovery and resolution of bugs. That means debugging and writing code. I am quite certain that you know that too. No-one who is actually involved in fixing bugs would rebuild the entire project plus all its dependencies just to test a bug fix. So, I wonder: other than creating the appearance of "doing development" [ when in fact no such thing is really taking place here ], what is the actual benefit of this build system change ? There seems to be some confusion here as to what "development" really means. It doesn't mean endless tinkering with the build system, or endless rewriting of spec files. A build system is a means, not a goal. I've had this discussion many times, and it seems that this endless tinkering with the build system is now a goal. -- Stefan Teleman KDE e.V. stefan.teleman at gmail.com
