> Note that instead of a SAL_WARN as you have, I output the undefined value
> as a number. That is more useful.
>
>
... because if somebody would happen to notice a warning "Unknown
RectanglePoint Value", what would their first reaction be?
Exactly, "Infuriating, why can't it then show *what* the
> OUString RectanglePointToOUString(const css::drawing::RectanglePoint& rp){
> if(rp == css::drawing::RectanglePoint::LEFT_TOP)
> return OUString::createFromAscii("LEFT_TOP");
> ...
> SAL_WARN("sd","Unknown RectanglePoint Value");
> return OUString::createFromAscii("");
> }
>
>
Hi,
I decided to try to fix the errors in the macros I have just commented
out or deleted so far, and most of them seemed successful.However one of
the errors start causing headaches on me(C++ newbie too), so the patches
is to be submitted later than I expected, neither this evening nor tonight.
=
> Where did you find the info that suggested these are necessary? If
> it's some wiki page, it would be good to fix it.
nowhere. I just read man thing-y for the command, and for some
options, I searched google, and for some other options, I read the
configure.ac and so on just to fill my self-sati
>
> --with-junit=...
> --with-ant-home=...
>
Unless you specifically plan to work on something Java-related, I would
recommend just using --without-java, and then you don't need any junit or
ant switches, and there is a significantly larger chance your build will
succeed.
--tml
__
On 3/29/2018 3:45 PM, Miklos Vajna wrote:
> The following switches are not necessary for a first debug build:
>
> - --disable-ccache
It is advised for Windows actually (which uses pch). Unless it's off by
default for Windows, it's better be used.
--
Best regards,
Mike Kaganski
Hi,
On Thu, Mar 29, 2018 at 05:32:00PM +0900, himajin10
wrote:
> SO THE COMMAND I USED WAS:
>
> /cygdrive/c/sources/libo-core/autogen.sh --enable-64-bit
> --enable-sal-log --enable-dbgutil --enable-selective-debuginfo="sw/ sc/
> vcl/ sax/ svx/" --with-lang="ja"
> --with-external-tar=/cy
> How exactly do you do your builds
As is often the case with newbies to a certain domain, people are often
afraid that they could have missed anything,
and want to get relaxed with full-feature option, and that's what
happened to me, as a newbie to OSS development.
I spent several hours reading
> I am one of those who would like to remove the debug levels, but lately
> (spending far too much time in the internal UNO workings), I am a little
> afraid that we have a lot of bit rotten code waiting to become a problem.
> So doing this change in a branch would be wise.
>
>
Here I am of a diffe
>
> As it happens, in LibreOffice code, "#ifdef DEBUG" is 1:1 equivalent to "#if
> (OSL_DEBUG_LEVEL >= 2)", and the thought was that perhaps all instances of
> "#ifdef DEBUG" should be changed to that instead, to make it more clear that
> it is a rather rare way to build, that code inside "#i
Funny this '#ifdef DEBUG' was brought up now, it happened to be discussed
on IRC yesterday.
As it happens, in LibreOffice code, "#ifdef DEBUG" is 1:1 equivalent to
"#if (OSL_DEBUG_LEVEL >= 2)", and the thought was that perhaps all
instances of "#ifdef DEBUG" should be changed to that instead, to m
On 28/03/18 12:45, himajin10 wrote:
Hello, I'm himajin10, often trying to make my own DEBUG build.
This mail is just for explanation.
I have written a bug report "tdf#116677:StylePool::createIterator has
default paramters, but StylePoolImpl's does not" , but there Xisco Faulí
kindly req
12 matches
Mail list logo
