+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
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
Software
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 certain
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 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 another
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 to
On Wed, 29 Jun 2011 17:56:42 +0200
Lubos Lunak l.lu...@suse.cz 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
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 don't
Hi Michael, all,
On Mon, 27 Jun 2011 12:03:16 +0100
Michael Meeks michael.me...@novell.com 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
Hi Michael, *,
On Mon, Jun 27, 2011 at 1:03 PM, Michael Meeks michael.me...@novell.com 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
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=
On Mon, Jun 27, 2011 at 6:03 AM, Michael Meeks michael.me...@novell.com 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 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 12:03 PM, Tor Lillqvist tlillqv...@novell.com 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
On Mon, Jun 27, 2011 at 12:26 PM, Norbert Thiebaud nthieb...@gmail.com wrote:
On Mon, Jun 27, 2011 at 12:03 PM, Tor Lillqvist tlillqv...@novell.com 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
On Mon, Jun 27, 2011 at 12:37 PM, Norbert Thiebaud nthieb...@gmail.com wrote:
On Mon, Jun 27, 2011 at 12:26 PM, Norbert Thiebaud nthieb...@gmail.com
wrote:
On Mon, Jun 27, 2011 at 12:03 PM, Tor Lillqvist tlillqv...@novell.com
wrote:
If we do that, we definitely should then also add built-in
On Fri, Jun 24, 2011 at 7:50 PM, Norbert Thiebaud nthieb...@gmail.com 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
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
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
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
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:
On Thu, Jun 23, 2011 at 6:35 AM, Michael Meeks michael.me...@novell.com 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.
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
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 2
On Thu, Jun 23, 2011 at 11:59 AM, Tor Lillqvist tlillqv...@novell.com 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
25 matches
Mail list logo
