On 07/03/12 03:22, Norbert Thiebaud wrote:
iow. the whole thing about 3.82 is slow is unfounded. Stock 3.82 _is_
slow because there was a bug that has been found and patched, even
up-streamed by michael IIRC... and that was almost a year ago now...
of course i meant stock 3.82 is slow, because
On Wednesday 07 of March 2012, David Tardon wrote:
On Wed, Mar 07, 2012 at 01:28:05AM +0100, Mat M wrote:
Hello
Could someone point to archive on choosing gnumake ?
I am surprised cmake was not elected, since the C means
cross-platform, and that is one basic of LO.
Sigh, life would
Speaking as someone who likes CMake
You may well be right, but right now the cost of switching the build
system on such a large project is simply prohibitive.
On 2012-03-07 13:57, Lubos Lunak wrote:
On Wednesday 07 of March 2012, David Tardon wrote:
On Wed, Mar 07, 2012 at 01:28:05AM
Hi,
On Wed, Mar 07, 2012 at 12:57:11PM +0100, Lubos Lunak wrote:
I'm not build system expert, but judging from my CMake experience in KDE,
[...]
If you want to start a discussion about the build system to use, you are two
years too late. Two years ago, gnu make was the best candidate and in
On 07/03/12 12:57, Lubos Lunak wrote:
On Wednesday 07 of March 2012, David Tardon wrote:
On Wed, Mar 07, 2012 at 01:28:05AM +0100, Mat M wrote:
Hello
Could someone point to archive on choosing gnumake ?
I am surprised cmake was not elected, since the C means
cross-platform, and that is one
Good evening!
So I can't let my mailbox for the day without you stiffing it with mails
:-)
I will answer -almpost- all mails because I liked the discussions and some
need my right of reply.
Le Wed, 07 Mar 2012 14:03:16 +0100, Michael Stahl mst...@redhat.com a
écrit:
On 07/03/12 12:57,
On Fri, 2012-02-10 at 11:34 +0100, Michael Stahl wrote:
that commit can't be the reason because the wildcards added there are
for source files and mmeeks' output shows headers which are never added
directly by gb_LinkTarget_add_*Object.
Hah - I think I was just being a dofus (again)
Don't see why we shouldn't maintain our own patched copy of gmake the same
way we maintain patched copies of other components.
On Tue, Mar 6, 2012 at 16:12, Michael Meeks michael.me...@suse.com wrote:
On Fri, 2012-02-10 at 11:34 +0100, Michael Stahl wrote:
that commit can't be the reason
On Tue, 2012-03-06 at 19:08 +0200, Noel Grandin wrote:
Don't see why we shouldn't maintain our own patched copy of gmake the
same way we maintain patched copies of other components.
There was a long discussion about this at the ESC :-) and I disagree
with the decision, am still
On 06/03/12 18:12, Michael Meeks wrote:
On Tue, 2012-03-06 at 19:08 +0200, Noel Grandin wrote:
Don't see why we shouldn't maintain our own patched copy of gmake the
same way we maintain patched copies of other components.
There was a long discussion about this at the ESC :-) and I
On Tue, Mar 06, 2012 at 07:56:20PM +0100, Michael Stahl wrote:
then we can consider making that release a pre-requisite for LO build...
And break the build on all distros who won't have it? No.
Even make 3.82 isn't yet everywhere because of it's incompatibilities (and as
it looks, even Debian
On 6 March 2012 19:56, Michael Stahl mst...@redhat.com wrote:
On 06/03/12 18:12, Michael Meeks wrote:
On Tue, 2012-03-06 at 19:08 +0200, Noel Grandin wrote:
Don't see why we shouldn't maintain our own patched copy of gmake the
same way we maintain patched copies of other components.
Hello
Could someone point to archive on choosing gnumake ?
I am surprised cmake was not elected, since the C means cross-platform,
and that is one basic of LO.
regards
Mat M
Le Wed, 07 Mar 2012 00:13:11 +0100, Matúš Kukan matus.ku...@gmail.com a
écrit:
On 6 March 2012 19:56, Michael
I just ran a make no-op (a make on a fully built product, which
presumably should expose the performance of make itself more than
anything else)
on a Windows VM, using _our_ 3.82 form dev-tools and _our_ 3.81 form dev-tools
the result are
3.82: 14m19.125 4m31.200 9m15.539
3.81: 14m20.618
On Tue, 2012-03-06 at 19:56 +0100, Michael Stahl wrote:
personally i'd be rather more thrilled if all those nice patches found
their way upstream and a new release were done (after we test it on all
platforms of course).
Sure - you can hope that these guys will release :-) but ... six
On Tue, Mar 06, 2012 at 05:12:56PM +, Michael Meeks wrote:
On Tue, 2012-03-06 at 19:08 +0200, Noel Grandin wrote:
Don't see why we shouldn't maintain our own patched copy of gmake the
same way we maintain patched copies of other components.
There was a long discussion about
On Wed, Mar 07, 2012 at 01:28:05AM +0100, Mat M wrote:
Hello
Could someone point to archive on choosing gnumake ?
I am surprised cmake was not elected, since the C means
cross-platform, and that is one basic of LO.
Sigh, life would not be complete without enthusiasts telling us we
should
Hi,
On Thu, Feb 09, 2012 at 09:23:56PM +, Michael Meeks wrote:
commit 6055a5df7b6e7452987a9584d10f436ca2d349fd
Author: Bjoern Michaelsen bjoern.michael...@canonical.com
Date: Fri Oct 7 16:40:22 2011 +0200
no more gbuild loops: break early on nonexistent objects (this commit
On 10/02/12 11:25, Bjoern Michaelsen wrote:
Hi,
On Thu, Feb 09, 2012 at 09:23:56PM +, Michael Meeks wrote:
commit 6055a5df7b6e7452987a9584d10f436ca2d349fd
Author: Bjoern Michaelsen bjoern.michael...@canonical.com
Date: Fri Oct 7 16:40:22 2011 +0200
no more gbuild loops: break
Hi,
On 2012-02-09 at 15:47 +0100, Andras Timar wrote:
Also check the version of make. make 3.81 shipped with cygwin is buggy.
Use make 3.82 from http://dev-www.libreoffice.org/bin/cygwin/make
Actually, I am not really happy with stock 3.82 either; on my Linux box,
it adds 5 unnecessary
On Thu, 2012-02-09 at 20:35 +0100, Jan Holesovsky wrote:
Also check the version of make. make 3.81 shipped with cygwin is buggy.
Use make 3.82 from http://dev-www.libreoffice.org/bin/cygwin/make
Actually, I am not really happy with stock 3.82 either; on my Linux box,
it adds 5
21 matches
Mail list logo
