On Tue, Sep 30, 2014 at 22:58:21 -0400, Mike Shal wrote:
> Right, so if I had 450 directories instead of 45, it would be 5s? And if I
> added a single file somewhere, it'd be 6s+5s == 11s before it starts
> compiling the new file?
Well, if you had 450 ways to build a single source tree, sure. I'm not
sure why you'd do it as part of your normal development cycle though; I
was just offering numbers for Ninja. These trees were a subset of the
cross product of:
compiler: {gcc, clang, clang-analyzer}
boost: {1.46.0, .., 1.52.0}
python: {none, 2.7, 3.3}
tooling: {none, valgrind, coverage}
It was meant as the "run every night" check, not "did the last change I
made work" cycles.
Anyways, for adding a new file, you'd have ~600ms for CMake -> Ninja
followed by the <1ms for Ninja to figure out what to do.
> I'm glad to hear you've improved the performance, I'm just pointing out
> that the "parse everything before doing anything" model is the wrong
> approach. Doubly so when you have this model twice - once for CMakefiles
> and once for ninja files.
How does Tup remember things like "where is ffmpeg?" if I always want to
use a custom built one, not the one on the system (say, by setting
PKG_CONFIG_PATH). Do I have to always have it in the environment when
building my project? How is not remembering things like that considered
part of the consistency and sanity of the build? With the two-phase
build, you can have it remember and stick with a specific set of
dependency information (also faster since you don't have to search for
it all the time). Same with compiler flags, capabilities, feature
checks, etc.
--Ben
--
--
tup-users mailing list
email: [email protected]
unsubscribe: [email protected]
options: http://groups.google.com/group/tup-users?hl=en
---
You received this message because you are subscribed to the Google Groups
"tup-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
