It could be argued that SIP is part of a broader toolchain
What does this have to do with SIP again? I don't remember GCC not
generating the object files if the source code is not changed.
A compiler takes one input file and creates one output file.
The granularity of SIP is different, it's taking multiple
inputs (via %Import) and creating multiple outputs. This
design poses a "choke point". I think being time-stamp
friendly is a way for SIP to compensate for this.
So, why can't you configure your build system so that it doesn't call SIP in
the first place if the header file has not changed?
Here is the scenario - the header foo.h is changed, triggering
SIP to regenerate the bindings. In most cases, the change to
foo.h doesn't affect the code that SIP outputs. Of the 250
.cpp files generated by SIP, 10 depend on foo.h. However,
all 250 are rebuilt due to SIP changing the time stamp.
That's a 25x slowdown that provides me more time to surf the
PyKDE mailing list... :-)
Perhaps our situation is not typical, it doesn't affect our
developers that _depend_ on our SIP bindings. But it certainly
affects development _upstream_ of the SIP bindings.
Imagine someone hacking away at Qt and depending on PyQt
based regression tests to know if they've broken anything...
That's my day-to-day situation in a nutshell...
Nigel
_______________________________________________
PyKDE mailing list [email protected]
http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
