On 06/07/2011 08:13, Marc-André Laverdière wrote:
+1
As a n00b, I'd like to encourage everyone to make things "just work"
for the next me. I nearly gave up so many times that removing all
roadblocks is really important.
So, in short: upstream upstream upstream!
Marc-André Laverdière
Softwar
+1
As a n00b, I'd like to encourage everyone to make things "just work" for
the next me. I nearly gave up so many times that removing all roadblocks
is really important.
So, in short: upstream upstream upstream!
Marc-André Laverdière
Software Security Scientist
Innovation Labs, Tata Consulta
Lubos Lunak wrote:
> > Also: This does not even have to be done intentionally -- some
> > performance hack might very well also accidentally fix an build
> > breaker.
>
> The world is not perfect. I think we all know. What is your point?
>
That the world is not perfect, and certain setups favour
On Wednesday 29 of June 2011, Bjoern Michaelsen wrote:
> On Wed, 29 Jun 2011 17:56:42 +0200
>
> Lubos Lunak wrote:
> > Correct me if I'm wrong, but I haven't seen proposals for any other
> > kinds of extensions to the gmake copy.
>
> yet.
So what? Are we in a kindergarten? If we say that no such
On Wed, 29 Jun 2011 17:56:42 +0200
Lubos Lunak wrote:
> Correct me if I'm wrong, but I haven't seen proposals for any other
> kinds of extensions to the gmake copy.
yet.
Also: This does not even have to be done intentionally -- some
performance hack might very well also accidentally fix an build
On Wednesday 29 of June 2011, Thorsten Behrens wrote:
> Lubos Lunak wrote:
> > It is not another dmake, as I understand it, as you cannot simply nuke
> > our dmake copy now and expect things to still work, whereas that would
> > work with a gnumake copy as long as that one's extensions were kept t
Lubos Lunak wrote:
> It is not another dmake, as I understand it, as you cannot simply nuke our
> dmake copy now and expect things to still work, whereas that would work with
> a gnumake copy as long as that one's extensions were kept to "unimportant"
> features like better debugging or perform
Hi Lubos, Hi Thorsten,
On Wed, 29 Jun 2011 16:59:51 +0200
Lubos Lunak wrote:
> If the extensions are pushed upstream, the copy is synced to
> upstream, and the extensions are not relied upon, I don't see why
> there should be a big problem as long as people find it worth it.
I see Thorstens poin
On Wednesday 29 of June 2011, Thorsten Behrens wrote:
> Michael Meeks wrote:
> > You know; the temptation to check-in and build our own gnumake is
> > growing on me ;-)
>
> You should resist that temptation. We'll end up with another dmake
> then, with lots of special sauce...
It is not anoth
Michael Meeks wrote:
> You know; the temptation to check-in and build our own gnumake is
> growing on me ;-)
>
You should resist that temptation. We'll end up with another dmake
then, with lots of special sauce...
Cheers,
-- Thorsten
pgpmF5FiOW3E7.pgp
Description: PGP signature
__
On Mon, Jun 27, 2011 at 12:37 PM, Norbert Thiebaud wrote:
> On Mon, Jun 27, 2011 at 12:26 PM, Norbert Thiebaud
> wrote:
>> On Mon, Jun 27, 2011 at 12:03 PM, Tor Lillqvist
>> wrote:
If we do that, we definitely should then also add built-in mkdir and cp
commands in it,
>>>
>>> Hmm, or
On Mon, Jun 27, 2011 at 12:26 PM, Norbert Thiebaud wrote:
> On Mon, Jun 27, 2011 at 12:03 PM, Tor Lillqvist wrote:
>>> If we do that, we definitely should then also add built-in mkdir and cp
>>> commands in it,
>>
>> Hmm, or actually, I don't think that will be such a great win after all, as
>>
On Mon, Jun 27, 2011 at 12:03 PM, Tor Lillqvist wrote:
>> If we do that, we definitely should then also add built-in mkdir and cp
>> commands in it,
>
> Hmm, or actually, I don't think that will be such a great win after all, as
> the gbuild recipies where tons of mkdir commands are being run typ
> If we do that, we definitely should then also add built-in mkdir and cp
> commands in it,
Hmm, or actually, I don't think that will be such a great win after all, as the
gbuild recipies where tons of mkdir commands are being run typically are in a
shell expression with && anyway, so they coul
> You know; the temptation to check-in and build our own gnumake is growing on
> me ;-)
If we do that, we definitely should then also add built-in mkdir and cp
commands in it, for the benefit of especially us poor Windows builders... But
probably pointless to try to upstream that.
--tml
On Mon, Jun 27, 2011 at 6:03 AM, Michael Meeks wrote:
>
> On Sat, 2011-06-25 at 15:44 -0500, Norbert Thiebaud wrote:
>> > I submitted the patch to the bug-make mailing list
>
> You know; the temptation to check-in and build our own gnumake is
> growing on me ;-) you know you want to (TM) ..
I'll add the internal gmake suggestion as a TSC topic for Thursday;
personally I'd love to have a nice, faster, internal, GPL licensed build
tool in our tree ;-)
On Mon, 2011-06-27 at 13:24 +0200, Bjoern Michaelsen wrote:
> @Michael: Did you try it again with "make -sr gb_CHECKOBJECTOWNER
Hi Michael, *,
On Mon, Jun 27, 2011 at 1:03 PM, Michael Meeks wrote:
> [...]
> You know; the temptation to check-in and build our own gnumake is
> growing on me ;-)
:-) I wouldn't object to this - as gnumake >=3.81 is a requirement
that has to be manually installed on Mac OSX 10.4/PPC, (a
Hi Michael, all,
On Mon, 27 Jun 2011 12:03:16 +0100
Michael Meeks wrote:
> It takes me only ~10 seconds to compile (and the same to
> configure (urk)) gnumake.
>
> My current incremental, no-op tail_build takes:
>
> real 0m18.519s
> user 0m17.679s
> sys 0m0.769s
>
> Whic
On Sat, 2011-06-25 at 15:44 -0500, Norbert Thiebaud wrote:
> > I submitted the patch to the bug-make mailing list
>
> Note that, even if the patch is accepted by upstream, based on their
> recent 'schedule', It won't probably be available in a 'realeased'
> version until 2014 or something... so d
On Fri, Jun 24, 2011 at 7:50 PM, Norbert Thiebaud wrote:
> I submitted the patch to the bug-make mailing list
Note that, even if the patch is accepted by upstream, based on their
recent 'schedule', It won't probably be available in a 'realeased'
version until 2014 or something... so don't hold yo
I submitted the patch to the bug-make mailing list
Norbert
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
On Thu, Jun 23, 2011 at 11:59 AM, Tor Lillqvist wrote:
> While I agree this is a great idea, would it be hard to make it a bit less
> verbose?
>
> I.e, instead of
>
>> ### call $(gb_Library_set_include) -->
>> ### arg 0 for call $(gb_Library_set_include) is 'gb_Library_set_include'
>> ##
While I agree this is a great idea, would it be hard to make it a bit less
verbose?
I.e, instead of
>### call $(gb_Library_set_include) -->
>### arg 0 for call $(gb_Library_set_include) is 'gb_Library_set_include'
>### arg 1 for call $(gb_Library_set_include) is 'msword'
>### arg
At 11:46am -0400 Thu, 23 Jun 2011, Norbert Thiebaud wrote:
On Thu, Jun 23, 2011 at 6:35 AM, Michael Meeks wrote:
On Thu, 2011-06-23 at 02:23 -0500, Norbert Thiebaud wrote:
So I created a patch for make-3.82 that allow the use of
--debug=e,c That add trace about, respectively, $(eval and
$(scall
On Thu, Jun 23, 2011 at 6:35 AM, Michael Meeks wrote:
> Hi Norbert,
>
> On Thu, 2011-06-23 at 02:23 -0500, Norbert Thiebaud wrote:
>> What I found was that the most confusing things to follow were $(eval
>> and $(call, especially when they cascade 4, 5, 6 level deep.
>
> Nice :-)
>
>> So I
At 9:06am -0400 Thu, 23 Jun 2011, Bjoern Michaelsen wrote:
On Thu, 23 Jun 2011 02:23:46 -0500 Norbert Thiebaud wrote:
So I created a patch for make-3.82 that allow the use of
--debug=e,c That add trace about, respectively, $(eval and $(scall
see:
http://cgit.freedesktop.org/libreoffice/contrib/d
Hi Norbert,
On Thu, 23 Jun 2011 02:23:46 -0500
Norbert Thiebaud
wrote:
> So I created a patch for make-3.82 that allow the use of --debug=e,c
> That add trace about, respectively, $(eval and $(scall
> see:
> http://cgit.freedesktop.org/libreoffice/contrib/dev-tools/commit/?id=a4f03f17f42ded70e6a
Hi Norbert,
On Thu, 2011-06-23 at 02:23 -0500, Norbert Thiebaud wrote:
> What I found was that the most confusing things to follow were $(eval
> and $(call, especially when they cascade 4, 5, 6 level deep.
Nice :-)
> So I created a patch for make-3.82 that allow the use of --debug=e,c
>
It is sometimes hard to follow what gbuild does internally... which
when gbuild has a bug, or when it is misused makes things quite
'interesting'...
What I found was that the most confusing things to follow were $(eval
and $(call, especially when they cascade 4, 5, 6 level deep.
So I created a pa
30 matches
Mail list logo
