Hello Walter,
BCS wrote:
Hello Andrei,
The idea is to not extract the files every time you build. If they
are in place already, the tool should recognize that.
The difference in speed between disk IO and CPU /might/ be high
enough that (unless the uncompressed file is cached or you round trip
it back to the disk) reading from the zip may be faster. I know that
on linux there is a way to pass a stream as a file name (I forget
what happens under the hood, but bash uses the ">(cmd)" syntax to do
it) so you could work with that.
I'd argue that for this case, caching the extracted files is not worth
the effort, complexity, or speed. If you're in an edit/compile/debug
loop, I can't see working off of a zip file of the sources.
The only case I can think of where putting a zip file in the middle of that
loop is even remotely reasonable would be for a remote build farm. The other
use cases for build-from-zip are building someone else's code where you aren't
editing the parts in the zip file.
--
... <IXOYE><
