not be taking sides in such politics, especially
given that the problem does not appear to be resolved or even having a
consensus.
On Thursday 18 of March 2021, Thorsten Behrens wrote:
> Lubos Lunak wrote:
> > I disagree with the plan. Git uses master, so we should stick with
> >
roblematic word, which would be way simpler and actually do
something related to the topic?
The way I see it, if this is supposed to fix something, then it actually
doesn't, and it can create technical problems. If it's supposed to do
something else, it's not up
s on
improper locking, but release builds still managed to cope with it somehow
(more often than not, anyway).
Developer builds should of course fall flat on their face in such cases, but
in practice it's probably better to value end product stability more than
practically
On Monday 08 of December 2014, Bjoern Michaelsen wrote:
> Hi Lubos,
>
> On Fri, Dec 05, 2014 at 06:46:17PM +0100, Lubos Lunak wrote:
> > On Thursday 04 of December 2014, Michael Meeks wrote:
> > > * Large scale renames (Kendy)
> >
> > ...
> >
> > >
+ would support better names for Writer (Bjorn)
> + can re-write classes with Clang ? (Michael)
Clang should be able to rewrite pretty much whatever would matter. E.g.
compilerplugins/clang/store/changefunctioncalls.cxx could be used to rename
all calls of a specific function.
o hide its boost
> usages from the header?
He can't. Signals usually form part of the public API of a class.
--
Lubos Lunak
l.lu...@collabora.com
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
a pointer to a member function, because that one requires
also the this pointer, so you need to go with boost::bind. See e.g. 96369e97.
--
Lubos Lunak
l.lu...@collabora.com
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.f
integrated,
for icecream I have a patch but compilers do not allow specifying proper path
refering to the .dwo file when building in a different path).
--
Lubos Lunak
l.lu...@collabora.com
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.
n-hidden visibility).
Given we have SAL_DLLPUBLIC_TEMPLATE, it seems likely that there shouldn't be
any big trouble there.
--
Lubos Lunak
l.lu...@collabora.com
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
y
> http://www.gnu.org/software/libc/manual/html_node/Backtraces.html
Sadly, it'd also break it considerably. Unless that has improved recently
(which I doubt), things like hidden symbol visibility make these functions
practically useless.
--
Lubos Lunak
l.lu...@collabora.com
___
his instead of the primitive&working way of having parents
responsible for cleaning up their children on destruction? Stack-allocated
objects is probably the most sensible C++ lifecycle management ever, so if it
doesn't work with vcl, vcl has got to be seriously broken in that regard.
--
or
> libreoffice-4-3, but it was a mistake. I reverted it.
My bad, the original code had several unhandled switch cases together and I
overlooked that (not that I get how the fix worked in master).
Andras, could you please include the commit back to 4.2+4.3 together with
74c6ba1b741ae76a
to use <http://people.centos.org/tru/devtools-2/> for Linux
> extensions). In other words, all the include files that end up copied
> to the SDK's include/ directory still need to be compileable by a
> non-C++11 compiler.
But we are only people, so I added checking of this to the odk checka
w, argh...
I think the call to isInMainFile() should not use spellingLocation, but just
the location given by functionDecl->getLocation() .
--
Lubos Lunak
l.lu...@collabora.com
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
at's exactly the point of what Max says. The warning is not bogus.
Using a dynamic_cast where a static_cast is known to work well is a sign of
the un-debuggable world of defensive programming that you speak of.
--
Lubos Lunak
l.lu...@collabora.com
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
7;t work. Do not use those C(XX)FLAGS you used (and I'll remove
that from the wiki, it was apparently a bad idea to have it there).
--
Lubos Lunak
l.lu...@collabora.com
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
ntation of the number, it
doesn't say whether hex will be uppercase or lowercase. The question is of
course how much code makes an assumption about this and whether the change is
worth it.
--
Lubos Lunak
l.lu...@collabora.com
___
> http://stackoverflow.com/questions/936687/how-do-i-declare-a-2d-array-in-c-
>using-new) Any idea?
The sizes are constants, there's no such problem.
--
Lubos Lunak
l.lu...@collabora.com
___
LibreOffice mailing list
LibreOffice@lists.fre
On Thursday 17 of April 2014, Lubos Lunak wrote:
> On Wednesday 16 of April 2014, Stephan Bergmann wrote:
> > Jan-Marek, all,
> >
> > Any details on the reason for the revert, and whether it could be the
> > cause for the newly seen crash?
>
> KDE4 file dialo
gt; "Revert 'Rewrite Qt4 based nested yield mutex
> > locking,'" but unfortunately without any rationale.
> >
> > So it looks somewhat plausible that this got broken again (if it ever was
> > actuall
x27;s use, and convert or reuse back
when writing out a document.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
ying
font system supports and then just uses it normally as if it was a system
font).
There's a class EmbeddedFontsHelper in VCL that I created for handling
embedded fonts, that should be the place to start if you want to give
implementing this a try.
--
Lubos Lunak
l.lu...@suse.cz
diff --
but I don't have an estimate for download. MSVC
downloads only those .pdb files it actually needs, and it can cache them
locally, so it's hopefully not that much.
- is there any other option I should be asking :) ?
Attached is a tinderbox master.sh script I currently use.
--
ormat really called OOoXML? Seeing this commit made me
pretty confused until I figured out after a while that it has in fact nothing
to do with OOXML.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
UNO code less "noisy".
> > And it matches the natural semantics of C++, which is that it's possible
> > to pass a subtype of the expected parameter's type.
>
> hmmm... looking at the amount of boilerplate involved one gets
(call
gb_StaticLibrary_use_externals,plugcon,gtk cairo))" helps with the problem,
but I assume this cannot be just hardcoded and I don't know how to do it
properly? Gbuild experts?
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freed
ich I expect should be
fairly easy to do and just needs somebody to do it. It it to be used like
other rewriters (see the README), expect it won't rewrite anything and only
generate the data.
There's no white-listing either, but that shouldn't be difficult, and the
code could
> I would suggest not to use clang if this is your first build. _If_ you use
> clang, be prepared to do some work to keep it running now and then.
Nah, the Clang build does not break more often than GCC build. But I don't
know if Clang-3.0 builds LO without proble
; get it to pass that.
Actually removing it is not a mistake. The macro is a cumbersome
micro-optimization and here it presumably doesn't make any difference. Just
calling matchIgnoreAsciiCase() should do.
Also note that LO has SAL_N_ELEMENTS macro for getting the numbe
On Saturday 06 of April 2013, Bjoern Michaelsen wrote:
> Just out of curiousity, what are the numbers for sc now, if you have them
> at hand?
make Library_sc
PCH: 5:18 (PCH creation is about 24 seconds).
non-PCH: 16:38
--
Lubos Lunak
l.lu...@s
tons of includes. Full rebuild of
master on Win86-6 is now something like 3 hours, without PCH it'd be at least
4 (I don't remember anymore and it'd take a while to measure).
I have not tried with GCC, and with Clang it's actually not worth it at all.
--
Lubos Lunak
l.lu...
oduce troubles like e.g.:
> - making linking against a 'private' header from another module a bit to
> easy
Both these ways, and the current way, make it about equally easy if one
really wants to do it.
> As you might guess, if we go for this I would clearly prefer the first
and won't as long as it takes that
much time it takes.
I actually agree with Terence. If a library changes, its dependent libraries
should change and thus relink even without having .so <- .so dependencies. I
do not see a good use case where this would be a problem.
--
Lubos Lunak
On Friday 29 of March 2013, Noel Power wrote:
> On 29/03/13 16:18, Lubos Lunak wrote:
> > On Thursday 28 of March 2013, Noel Power wrote:
> > I have reverted this commit, as it fails on at least two 4-0
> > tinderboxes (Clang and Win-x86_6). I also couldn't find
ebc32fbe73c251719494fe
> Reviewed-on: https://gerrit.libreoffice.org/3064
> Tested-by: Petr Mladek
> Reviewed-by: Petr Mladek
I have reverted this commit, as it fails on at least two 4-0 tinderboxes
(Clang and Win-x86_6). I also couldn't find
On Tuesday 26 of March 2013, Peter Foley wrote:
> On Tue, Mar 26, 2013 at 2:19 PM, Lubos Lunak wrote:
> > That already exists: configure CC=clang CXX=clang++
> > What's the point of having such an explicit option? We already have
> > enough options that reinvent the
for MinGW cross-compilation.]),
> )
>
> +AC_ARG_ENABLE(clang,
> +AS_HELP_STRING([--enable-clang],
> +[Build using the clang compiler.]),
> +)
> +
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
t; source on a quick fly in the editor is easier for the eye.
>
> How do others see this?
I think there is still so much to do before arguing about spaces or other
similar matter of taste details that have very little practical consequences.
--
Lubos Lunak
l.lu...@suse.cz
and presumably they're both implemented the same way). I tried with
1 include files with GCC and the difference, if any, is just lost in the
noise.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
quot;
>
> The 2nd produces a 'failed' but not the first.
>
> Is there some way we can propagate the failure / exit code from the
> spawned process through icerun ? perhaps that is fixed already, I have:
>
> $ icerun --version
> ICERUN 0.9.98.3
Hmm ...
On Monday 18 of March 2013, julien2412 [via Document Foundation Mail Archive]
wrote:
> Hi Lubos,
>
> But which ones are the useless?
> QPalette::WindowText and QPalette::Window
> or
> QPalette::ButtonText and QPalette::Button
The ones which are not used.
--
Lubos Luna
(The
> style of above example would be fine with me.)
Yes, a script should be enough for this. And yes, "somebody" just needs to do
it :).
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
; (See
> http://opengrok.libreoffice.org/xref/core/vcl/unx/kde4/KDESalFrame.cxx#292)
>
> Must we keep QPalette::WindowText and QPalette::Window or
> QPalette::ButtonText and QPalette::Button ?
It looks like a leftover from the KDE3 version and if it's been
mehow ?
And do we need such a tool at all? If Glade is not capable of providing
sensible defaults for spacing and similar features, cannot our code for
loading the .ui files handle that?
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice
ossible to check mechanically, while I
do not see a way to prevent the problem above.
Opinions on this?
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
ut incorrect #include directives should not be left in
the sources, one way or another.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
at ?
I'd be interested too. I don't know about GCC (besides the rumour that PCH
there is fragile), but with Clang I actually couldn't see any noticeable
improvement when using PCH (barring the cases when it seems to make the
compile even slower for me for some reason). With MSVC the
ndly JunitTest_* target is just a phony
target depending on the .../done target, so they both should work.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
On Friday 22 of February 2013, Stefan Schick wrote:
> Hey,
> there are more translation patches to come in the next days...
>
> All of my past & future contributions to LibreOffice may be
>licensed under the MPL/LGPLv3+ dual license.
Pushed, thanks for the patch.
--
ich needs to re-start on
> > first start after any upgrade to cater for potential changes in bundled
> > extensions etc.).
>
> I followed the instructions here:
> https://wiki.documentfoundation.org/QA/HowToBibisect
I have edited the page to not recommend running the binary
On Friday 01 of March 2013, Christina Rossmanith wrote:
> Hi,
>
> Lubos Lunak has prepared a huge automatically generated patch removing all
> those ::rtl prefixes. So it is a little waste of time to prepare such
> patches manually. Instead maybe you could help removing
>
he
instsetoo_native gbuild conversion. The #7 tinderbox apparently builds fine,
but it looks like it doesn't create the .zip archives to upload, quite
possibly for similar reasons.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing lis
On Thursday 21 of February 2013, Michael Meeks wrote:
> Hi Lubos,
>
> On Mon, 2013-02-18 at 15:01 +0100, Lubos Lunak wrote:
> > > Heh; so "do not merge" is the equivalent of "do not submit" but much
> > > clearer and friendlier, fits inside the text
rit.libreoffice.org/2302 :-)
It is intentional that some C++11 features are used if available, in order to
provide various benefits (SAL_OVERRIDE for example).
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop
ding NUL bytes at places where the receiving side expects them,
> worked on a clean-up of that code, but didn't come around yet to push
> it. Will happen shortly.
I don't know what the code is supposed to do exactly, but just from looking
at it I agree with Matteo's c
e the overload that explicitly accepts length.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
On Wednesday 20 of February 2013, julien2412 [via Document Foundation Mail
Archive] wrote:
> Lubos Lunak wrote
>
> > On Tuesday 19 of February 2013, Julien Nabet wrote:
> >> diff --git a/desktop/source/app/officeipcthread.cxx
> >> b/desktop/source/app/officeipcthr
tes,
> nBufSz-nBytes))>0) { nBytes += nResult;
> if (pReceiveBuffer[nBytes-1]=='\0') {
> break;
> }
> }
> -/* make sure the buffer is \0 terminated */
> -if (nBytes > 0)
&
rol() doesn't get called anymore. As there have
been no other changes in the area, I suspect this commit. Could you please
have a look?
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
On Monday 18 of February 2013, Tom Tromey wrote:
> >>>>> "Lubos" == Lubos Lunak writes:
>
> Lubos> This could be very useful ('catch throw' is so cumbersome in
> Lubos> gdb),
>
> Is there something we could do to improve it?
I don&#x
the practice with tinderboxes is often that if one of them
collects a larger number of commits between two rebuilds, then if a breakage
shows up, nobody seems to feel responsible. So, if possible, I think it'd be
better if this was run more often than 2-3 weeks, possibly as another
tin
On Saturday 16 of February 2013, Michael Meeks wrote:
> On Fri, 2013-02-15 at 21:50 +0100, Lubos Lunak wrote:
> > > PPS: please do not shoot the messenger...
> >
> > I'm not shooting the messenger, I'm telling him that the way it is he'll
> &g
;s a good or bad idea) or some other way
would need to be found.
- it'd be good to know how fast/slow the function is. Exceptions generally
aren't very fast, but if the function was called every time in the ctor, then
depending on fast it is that might make it debug-build-only feature.
-
(although as Norbert said
> to push the change you would need to bypass gerrit anyway, but we dont have
> to rub that it) and 'consensus'/'discussion' gives a clear road on how to
> proceed for the contributor.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
On Friday 15 of February 2013, Norbert Thiebaud wrote:
> On Fri, Feb 15, 2013 at 12:36 PM, Lubos Lunak wrote:
> > That should be made more obvious in the wording then. I normally use
> > -1/-2 as the reverse of +1/+2
>
> Well, there are not symetrical:
Yes, I get that now.
ing then. I normally use -1/-2 as
the reverse of +1/+2 and the current 'do not merge' is vague enough to mean
anything in that direction. It should include 'I disagree with the change' or
similar.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
assSet/Jar/unoloader/done] Error 1
> make[1]: *** Waiting for unfinished jobs
Running 'make VERBOSE=1' will show you also the executed commands, so you can
find the failing one and debug what the problem is.
--
Lubos Lunak
l.lu...@suse.cz
_
ce/UI/GenericCommands.xcu . How do
I get the UI strings for the usage in the code (i.e. including l10n) and,
since I assume that includes removing it from the .xcu file, will something
else be affected by that?
--
Lubos Lunak
l.lu...@suse.cz
void SvxFontNameBox_Impl::CheckAndMarkUnknownFont( const OUS
@ -57,6 +57,7 @@ certain functionality.
>
> @li @c desktop
> @li @c desktop.deployment
> +@li @c desktop.migration
Note that the idea is that next to the area name there is a very short
description of it (especially for the non-obvious ones).
--
Lubos Lunak
l.lu...@suse.cz
_
and the builtins are already LO-specific code anyway.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
ld includes only LinkTarget .d, not object .d files . And
LinkTarget .d files are dummies (just like object .d files) during the first
build, during that build object .d files are updated while building the
targets, and before second build LinkTarget .d files are created from
object
give it a spin.
It doesn't even build on Windows because of a stray SAL_CALL, see
668bec99efb4a15ca0fe364fa3c217baba8a6f27 .
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
rything is built from
tail_build, it would be equivalent to 'make 2>&1 | tee build_error.log' .
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
t copied to solver, and installer creation failed.
> Also it did not work in VC90 case.
So why is this not said in the commit log message? As it is, there was no way
to find out what your commit was actually about, other than the obvious.
--
Lubos Lunak
l.lu...@suse.cz
_
On Monday 21 of January 2013, Stephan Bergmann wrote:
> On 01/21/2013 06:05 PM, Lubos Lunak wrote:
> > On Monday 21 of January 2013, Stephan Bergmann wrote:
> >> While the gotcha of printing a large unsigned value as a negative value
> >> thanks to calling rtl_ustr_value
blematic ones. Given that a number of system typedefs are internally
unsigned integers despite all the signed vs unsigned trouble this causes,
usage of the type is much more likely than usage of a problematic value of
the type, so IMO it makes mo
nge and
didn't get this one quite right.
> If testintrosp.cxx is still used, an idea how to make this line more clear
> (and perhaps removing the double use of OUString)?
aRetStr += " (Typ: " + xIdlClass->getName() + ")";
--
Lubos Lunak
l.lu...@suse
chosen over
unsigned char AKA sal_Bool , so Caolan added it in
e8bbb76827dd7a0e30d7d1db34a812a84d85f390
- if SvStream gets overload for bool, the warning can be dumped
Or am I missing something there?
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreO
I've commented out calling this specific test, until it gets
fixed.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
overloads, for anything except signed/unsigned char/short:
On Friday 11 of January 2013, Lubos Lunak wrote:
> So, based on this, the best solution to the problem that I can see is
> creating fromNumber() or number() , overloaded for all signed/unsigned
> int/long/long long types and all flo
OUString
> convertion have to be carefully audited by hand,
What you wrote above is AFAIK not written down anywhere, not in the wiki
page, not in the (non-existent) String class documentation, so any bets on
what the reality is?
Could you please add these cases to the strin
On Friday 11 of January 2013, Jean-Noël Rouvignac wrote:
> 2013/1/10 Lubos Lunak
>
> > > > Unless all you want to convert is only places which do the explicit
> > > >
> > > > cast, this will need a (fairly simple) Clang plugin.
> > >
> >
On Friday 11 of January 2013, Noel Grandin wrote:
> On 2013-01-10 15:55, Lubos Lunak wrote:
> > - There's no need for valueOfChar(). There is already OUString ctor from
> > sal_Unicode, so the valueOf() overload for it is just making an obvious
> > thing complicated. Code
't the new flags be initialized in gb_LinkTarget_LinkTarget?
- (as a general rule) for non-obvious commits, please include in the commit
log message not only what but also why, such as a link to this thread. In a
year somebody's bound to want to reshuffle the f
4.0.1, right?). Try if the file compiles successfully with 'make
DEBUG=1', that will disable optimizations.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
d, it's better to fix it completely rather
than just slightly reduce the problem. And for that it would be better to
remove the original valueOf() completely, and that results in all the
follow-up issues that I raised.
--
Lubos Lunak
l.lu...@suse.cz
On Saturday 05 of January 2013, Michael Meeks wrote:
> On Fri, 2013-01-04 at 15:12 +0100, Lubos Lunak wrote:
> Having said that - it is something we really want to do; can we drop
> the published easy hack bug in this regard (or just close it) to avoid
> the drip of patches there
On Thursday 10 of January 2013, Tomáš Chvátal wrote:
> 2013/1/10 Lubos Lunak :
> >> As written in subject the variable is used on multiple targets and it
> >> ignores the user defined cflags/cxxflags.
> >> This should never happen and all our targets should take int
On Thursday 10 of January 2013, Noel Grandin wrote:
> On 2013-01-10 15:55, Lubos Lunak wrote:
> > - There's no need for valueOfChar(). There is already OUString ctor from
> > sal_Unicode, so the valueOf() overload for it is just making an obvious
> > thing complic
e default noopt flag to use when doing debug build. And I don't
quite understand why you'd want this change, what problem are you trying to
solve?
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
htt
- some regular expression magic will do most of the
> work.
I expect it won't, regular expressions can't tell what foo is in "valueOf(
foo )". Unless all you want to convert is only places which do the explicit
cast, this will need a (fairly simple) Clang plugin.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
On Thursday 10 of January 2013, Michael Meeks wrote:
> On Wed, 2013-01-09 at 20:01 +0100, Lubos Lunak wrote:
> > Looks what I found under the tree! Faster make for Cygwin. Granted, I had
> > put it there first, but still nice.
>
> Nice work ! :-)
>
> I'
argument first to convert from the cygwin
> filesystem structure to the Win32 representation.
> i.e. from "/cygdrive/C/libo" to "C:\libo"
I have not done this, apparently make always gets windows paths when building
LO, or does somebody have a problem with this (builtins ha
version and if it's really needed this way? It dates back to 2009, so repo
history is as usually useless.
[*]
ERROR: The following files could not be found:
ERROR: File not found: Microsoft.VC80.CRT.manifest
ERROR: File not found: msvcp80.dll
ERROR: File not found: msvcr80.dll
--
Lubos Lu
gt; way.
>
> Hmm, if I try and build just unotools, I get the following error when
> building unotools_inc :
> gb_Deliver-deliver : file does not exist in solver, and cannot be
> delivered :
> /Users/Shared/Repos/LO/core/solver/unxmacxi.pro/lib/libcomphelpgcc3.dylib
make
‘valueOf(sal_Unicode&, int)’ is ambiguous
Should be fixed now.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
On Wednesday 09 of January 2013, Lubos Lunak wrote:
> Looks what I found under the tree! Faster make for Cygwin. Granted, I had
> put it there first, but still nice.
>
> Those of you who build on Windows, you might want to pull again from
> git://gerrit.libreoffice.org/dev-tools
On Wednesday 09 of January 2013, Lubos Lunak wrote:
> Looks what I found under the tree! Faster make for Cygwin. Granted, I had
> put it there first, but still nice.
Oh well, looks like somebody actually does develop LO on Windows :). So on a
related note, two more things that might be h
some simple commands used by gbuild such as
mkdir or cp, and since fork() is pretty slow on Cygwin, this makes some
operations such as delivering noticeably faster. Tinderbox #6 has been using
it for two weeks without a problem.
--
Lubos Lunak
l.lu...@su
a shell? Why would openSUSE do that in the first place?
It's when building RPM packages, which are supposed to be built with
$RPM_OPT_FLAGS.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
1 - 100 of 726 matches
Mail list logo
