[Libreoffice] Comments on Changes in svtools/source/svhtml/htmlkwd.cxx
nthiebaud at gmail.com
Sun Jun 5 11:11:03 PDT 2011
commit libs-gui:b247a329c5ca9f8cd1e84fbaca3456be71a87fbf Removed
lines from merge conflicts
When you run into a hick-up like that (a belated gitt pull -r that
conflicted right ?), and that is _before_ you pushed the offending
commit, it would be nicer to 'amend' the previous commit to fix it
rather than let the unbuildable error and it correction stand.
Right now, I suggest that to make things easier to read (I had to read
the patch because of a bug... see below)
But in the near future, we will be able to use git-bisect in tinderbox
and for it to be effective we must thrive to have the product build at
every commit as much as possible.
the reason I browse these commits is because I'm seeing:
[ build CXX ] svtools/source/svhtml/htmlout
/lo/tb/svtools/source/svhtml/htmlkywd.cxx: In function 'sal_uInt32
/lo/tb/svtools/source/svhtml/htmlkywd.cxx:1028: error: new declaration
'sal_uInt32 GetHTMLColor(const String&)'
ambiguates old declaration 'sal_uIntPtr GetHTMLColor(const String&)'
make: *** [/lo/tb/solver/350/unxlngx6.pro/workdir/CxxObject/svtools/source/svhtml/htmlkywd.o]
make: *** Waiting for unfinished jobs....
dmake: Error code 2, while making 'all'
that seems to come from essentially from
The thing is that solar.h define:
typedef sal_uIntPtr sal_uLong; /* Replaces type ULONG */
so substituting sal_uLong with sal_uInt32 is not a neutral
replacement. on 64 bits machine that actually change things.
Now, I'm not arguing that in that particular case sal_uIntPtr make
more sens (I do think that sal_uInt32 is saner here), but sadly the
change has apparently deeper consequences that need to be ironed out.
More information about the LibreOffice