[PyKDE] Re: sip-4 vs sip-3

[Phil Thompson]

On Monday 01 December 2003 11:45 am, Gerard Vermeulen wrote:
> On Mon, 1 Dec 2003 07:50:52 +0000
>
> Phil Thompson <phil at riverbankcomputing.co.uk> 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