On Monday 01 December 2003 11:45 am, Gerard Vermeulen wrote:
On Mon, 1 Dec 2003 07:50:52 +
Phil Thompson [EMAIL PROTECTED] wrote:
On Monday 01 December 2003 7:34 am, Gerard Vermeulen wrote:
Phil,
In developing PyQwt, I use two tricks to minimize the build time after
fixing bugs or adding new methods:
(1) 'smart' copying of sip's output from a buffer directory to the
source directory (only copy when two sip output files differ below the
time stamp comment at the top).
(2) use of ccache
In this respect sip-4 is a step back compared to sip-3. With sip-4,
Addition of a single method to a single sip file leads always to a
complete rebuild of PyQwt. In addition, ccache is far less efficient
with sip-4 than with sip-3.
One of the reasons (I hope the only one) is the fact that sip-4 is
generating names as sipNm__qwt_5151 instead of the old symbolic
sipName_QwtWheel. Presumably adding a new method, propagates different
sipNames into all the sip-generated *.{cpp,h} files.
Could it be possible to go back to the symbolic names, or use names
like sipNm_ModuleName_ClassNumber_AttributeNumber to minimize changes
in the generated source code?
I don't think that would make any difference - a name is a name whether
it's symbolic or based on a number.
That is true for humans, but not for all computer programs.
The symbolic names in sip-v3 do not change if a new method gets added to
a sip-file. In sip-v4, a new method will produce a number-based name
that gets added somewhere in the middle of a long list. Names for class
methods later in the list will become different.
Characteristics of the sets of *.{cpp,h} generated by sip-v3 and sip-v4,
starting from two sets of sip files with as only difference the addition of
a single method to a single class, are:
sip-v3: only a few files are different. Those are the cmodule file and the
file corresponding to the changed classes. All the other files are
essentially the same (except for the time stamp header).
sip-v4: (almost?) all files are different, because the names based on a
number scheme have been changed.
The new build system generates Makefiles that has a very simplistic vew
of dependencies - I suspect this is the cause.
I am still using my distutils tools (with smart copy, the ccache program,
automatic production of an *.exe installer on Windows eventually, very
easy to adapt for wrapping other libs).
With sip-v4, my smart copy scheme only works for bug fixes. Not for
addition or removal of class members, because a lot of sipNames may have
been changed between the two sip runs (before and after the addition or
removal of members). Mixing sip-4's output of two such runs will surely
lead to disaster. With sip-3, this is no problem.
Consequently, after an addition or removal of a class member in a single
sip file, the smart copy scheme will lead to two files to recompile with
sip-3 but to almost all files with sip-4.
The ccache program calculates a hash for each input file to reduce g++'s
workload, therefore it also suffers from the (extraneous) renaming.
I understand that module size may be a reason for names like
sipNm_ModuleName_Number instead of the symbolic names, but from my point of
view a scheme like sipNm_ModuleName_ClassNumber_AttributeNumber would be
less likely to interfere with my tricks to reduce the build time.
Ok - I could fix it for names, because names aren't shared between modules.
(At one point they were which is how they acquired numerical names.) But
there are other things which I can't fix it for - type structures, virtual
handlers, anything that is part of the low-level API exported from one module
to another and are stored in tables. Changing the module is always going to
potentially change the order of the contents of those tables.
Note that if you do change a module you should increment the version number in
%Module statement. That's used at run-time to check you are running modules
that are compatible with each other.
Phil
___
PyKDE mailing list[EMAIL PROTECTED]
http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
