Hi Michael,
On Mon, 2012-02-13 at 16:06 +0100, Michael Stahl wrote:
(of course i don't care if you do it for a special merged libs mode,
but C++ development is already a sufficiently unproductive activity that
we shouldn't make it even more so...)
Is it necessary to build with full
On 14/02/12 11:52, Michael Meeks wrote:
Hi Michael,
On Mon, 2012-02-13 at 16:06 +0100, Michael Stahl wrote:
(of course i don't care if you do it for a special merged libs mode,
but C++ development is already a sufficiently unproductive activity that
we shouldn't make it even more so...)
Hi Michael,
On Tue, 2012-02-14 at 13:07 +0100, Michael Stahl wrote:
the problem is more likely that in tail_build we first compile all the
object files, and only after they have all been built they are linked
into libraries/executables.
Perhaps; could it also be that we like to
Hi,
Added Tom to the CC, see thread here:
http://thread.gmane.org/gmane.comp.documentfoundation.libreoffice.devel/24055/focus=24096
(Although it seems posts from non-subscribers, aka me, are not allowed,
so you won't see my earlier reply there. I'll send it to you separately.)
On Tue, Feb 14,
On Tue, Feb 14, 2012 at 10:52:31AM +, Michael Meeks wrote:
On Mon, 2012-02-13 at 16:06 +0100, Michael Stahl wrote:
(of course i don't care if you do it for a special merged libs mode,
but C++ development is already a sufficiently unproductive activity that
we shouldn't make it even
On 2012-02-14 14:22, Michael Meeks wrote:
Perhaps; could it also be that we like to compile with gcc in some
eight way parallel way, but when it comes to linking, we -really-
don't want to bog our machine down in that way ? I wonder if we could
explicitly limit parallelism of linking in some
Do we really need to keep analysis and date as separate shared
libraries? Would it be OK to move their source code over to the sc
module, and merge their objects into the sc library, and their
.component files into sc.component?
Probably the code that refers to them could be simplified a bit
On 13/02/12 12:31, Tor Lillqvist wrote:
Do we really need to keep analysis and date as separate shared
libraries? Would it be OK to move their source code over to the sc
module, and merge their objects into the sc library, and their
..component files into sc.component?
is that really
is that really necessary?
No, so OK, not then.
--tml
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
On Mon, 2012-02-13 at 12:38 +0100, Michael Stahl wrote:
the sc, sd, sw libraries already take forever to link with full debug,
You link with full debug ? :-)
and adding more stuff to them would also impact startup performance for
the respective application.
Not necessarily;
On Mon, 2012-02-13 at 13:31 +0200, Tor Lillqvist wrote:
Do we really need to keep analysis and date as separate shared
libraries ?
Ho hum; well - they are not used at calc startup, but they are at
document load - as soon as you start to enter a formula they are loaded,
and if you load
On 13/02/12 15:47, Michael Meeks wrote:
On Mon, 2012-02-13 at 12:38 +0100, Michael Stahl wrote:
the sc, sd, sw libraries already take forever to link with full debug,
You link with full debug ? :-)
well i was actually surprised once that i do, but soon found out that
somebody has
Hi Tor,
On Monday, 2012-02-13 13:31:11 +0200, Tor Lillqvist wrote:
Do we really need to keep analysis and date as separate shared
libraries? Would it be OK to move their source code over to the sc
module, and merge their objects into the sc library, and their
.component files into
13 matches
Mail list logo
