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 a
écrit:
On 07/03/12 12:57, Lubos Lunak wrote
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,
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
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 +01
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, l
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, becau
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
shoul
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 ab
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 ... s
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 4m39.2
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 a
écrit:
On 6 March 2012 19:56, Michael Stahl wrote:
On 06/03
On 6 March 2012 19:56, Michael Stahl 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.
>>
>> Ther
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 w
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 :-) a
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 suffer
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 wrote:
>
> On Fri, 2012-02-10 at 11:34 +0100, Michael Stahl wrote:
> > that commit can't be the reason because the wildcards
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)
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
>> Date: Fri Oct 7 16:40:22 2011 +0200
>>
>> no more gbuild loops: break early on nonexistent
Hi,
On Thu, Feb 09, 2012 at 09:23:56PM +, Michael Meeks wrote:
> commit 6055a5df7b6e7452987a9584d10f436ca2d349fd
> Author: Bjoern Michaelsen
> Date: Fri Oct 7 16:40:22 2011 +0200
>
> no more gbuild loops: break early on nonexistent objects (this commit
> breaks multi-repo support)
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 unne
20 matches
Mail list logo
