Christina. 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. Now, 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 GetHTMLColor(const String&)': /lo/tb/svtools/source/svhtml/htmlkywd.cxx:1028: error: new declaration 'sal_uInt32 GetHTMLColor(const String&)' /lo/tb/solver/350/unxlngx6.pro/inc/svtools/htmltokn.h:50: error: ambiguates old declaration 'sal_uIntPtr GetHTMLColor(const String&)' make[1]: *** [/lo/tb/solver/350/unxlngx6.pro/workdir/CxxObject/svtools/source/svhtml/htmlkywd.o] Error 1 make[1]: *** Waiting for unfinished jobs.... dmake: Error code 2, while making 'all' that seems to come from essentially from libs-gui:b8e4fae544147f9af83ec811bac49662481305f4 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. Norbert _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
