Re: [Libreoffice] patch for make to help in gbuild debugging
+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 Consultancy Services Hyderabad, India On 06/30/2011 12:54 PM, Thorsten Behrens wrote: 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 moves. But I think we're starting to talk past each other. Let's not waste more time on this, until there's more than just idle thoughts on either side. Cheers, -- Thorsten ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] patch for make to help in gbuild debugging
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 Security Scientist Innovation Labs, Tata Consultancy Services Hyderabad, India On 06/30/2011 12:54 PM, Thorsten Behrens wrote: 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 moves. But I think we're starting to talk past each other. Let's not waste more time on this, until there's more than just idle thoughts on either side. Cheers, -- Thorsten ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice The problem I think even if we submit upstream patches its down stream distros that sometimes take a while to update their development stacks such as make. One distro in particular is ubuntu sometimes, they have the latest and greatest, other times you need to push them to update, or push a newer version to upstream debian for it to wind its way down stream into ubuntu. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] patch for make to help in gbuild debugging
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 moves. But I think we're starting to talk past each other. Let's not waste more time on this, until there's more than just idle thoughts on either side. Cheers, -- Thorsten pgp4cQglh3xCE.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] patch for make to help in gbuild debugging
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 ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] patch for make to help in gbuild debugging
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 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 performance. 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. During the 3.x times KDE used a home-brewn automake+make replacement (called unsermake ... don't ask) that supported a subset of automake+make functionality and while people could still build using automake+make if they wished so for whatever strange reason, using unsermake was just so much better. -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] patch for make to help in gbuild debugging
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 unimportant features like better debugging or performance. If the extensions are pushed upstream, the copy is synced to upstream, and the extensions are not relied upon, A few too many ifs to make me feel comfortable. You end up with not being able to build without the in-tree gmake in no time - and bingo, you're coding against a single implementation again. How exactly is one supposed to end up not being able to build without the in-tree gmake if that gmake only has extensions for easier debugging and faster building? Correct me if I'm wrong, but I haven't seen proposals for any other kinds of extensions to the gmake copy. Besides, the only important if above is actually the one about not relying on the copy. The rest is irrelevant for those who simply would not use the copy for whatever reason. During the 3.x times KDE used a home-brewn automake+make replacement (called unsermake ... don't ask) that supported a subset of automake+make functionality and while people could still build using automake+make if they wished so for whatever strange reason, using unsermake was just so much better. I fail to see the point you're trying to make - the proposal at hand looks more like a superset, not a subset. ;) A superset of what? Just because this thread started with a patch adding some non-crucial functionality doesn't mean there has to be any superset as far as the actual building goes, and if there was any such proposal I must have missed it. And it may very well be a subset if it's found out that some stone-age make feature like built-in rules are making it slower and we just stop using it and turn the support for it off in our copy. The point I was trying to make was that it's doable. Sure, LO has a lot of OOo heritage of doing retarded things just because of the fun of it all over the place, but that doesn't mean we have the keep the tradition, do we? If we can without trouble implement the rule of reviewing patches before backporting, surely we can as well implement the rule of not actually relying on our own build tool copy again. -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] patch for make to help in gbuild debugging
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 fix an build breaker. Best, Bjoern -- https://launchpad.net/~bjoern-michaelsen ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] patch for make to help in gbuild debugging
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 hold your breath. You know; the temptation to check-in and build our own gnumake is growing on me ;-) you know you want to (TM) ... IMHO there are a few nonsensical things that are done of utter pointlessness in there. It takes me only ~10 seconds to compile (and the same to configure (urk)) gnumake. My current incremental, no-op tail_build takes: real0m18.519s user0m17.679s sys 0m0.769s Which seems too slow (and it's set to get worse) - 500ms or more of that seems to be in verify_file_database() eg. which just wanders around banging on the L2 cache checking strings are still strings to no useful purpose ;-) but no doubt there is a lot more that we can do to get this improved. ATB, Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] patch for make to help in gbuild debugging
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 0m0.769s Which seems too slow (and it's set to get worse) - 500ms or more of that seems to be in verify_file_database() eg. which just wanders around banging on the L2 cache checking strings are still strings to no useful purpose ;-) but no doubt there is a lot more that we can do to get this improved. Waiting for a 2014 release is cleary not nice. IMHO we should still get our stuff upstream, because diverting from upstream might create new interesting problems. So my proposal would be: - upstream patches - get them through some basic review upstream - add them to our patched version when reviewed upstream This way our patched version will: - not featurecreep away from upstream - get reviews by upstream - essentially be a prerelease of an upcoming make version - allow distros to still build with their default make by backporting the same patches that we do @Michael: Did you try it again with make -sr gb_CHECKOBJECTOWNER= because the checks for duplicate objects create some huge strings(*). Best, Bjoern (*) http://nabble.documentfoundation.org/gbuild-use-gb-CHECKOBJECTOWNER-to-check-for-double-linked-objects-td2827818.html ATB, Michael. -- https://launchpad.net/~bjoern-michaelsen ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] patch for make to help in gbuild debugging
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 Mac OSX 10.4/PPC, (as XCode 2.x only comes with make 3.80) you know you want to (TM) ... IMHO there are a few nonsensical things that are done of utter pointlessness in there. Getting rid of those will be an additional benefit. ciao Christian ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] patch for make to help in gbuild debugging
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= because the checks for duplicate objects create some huge strings(*). nice - that is better: real0m12.445s user0m11.611s sys 0m0.771s vs. real0m18.068s user0m17.193s sys 0m0.805s without it; so ~6 secs difference; I wonder if tail-build should perhaps turn that off, leaving it for developers to see when they re-build just their piece [ inconsistent I know but ... ;-]. Thanks, Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] patch for make to help in gbuild debugging
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 want to (TM) ... IMHO there are a few nonsensical things that are done of utter pointlessness in there. I wouldn't mind so long as we keep that in dev-tools and don't mess with the main repos. iow: we build by default with the 'standard' make, but direct dev that are interested to dev-tools to get a better 'make'. Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] patch for make to help in gbuild debugging
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 ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] patch for make to help in gbuild debugging
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 are being run typically are in a shell expression with anyway, so they couldn't be run as built-in simple make commands anyway. Forget it. Yeah, but maybe there is something to be investigated to avoid fork when running recipies... I've read somewhere that spawn was much more performant than fork under cywin (note: I don;t know if make already do that or not, nor what are the implication...) Another thing: I think most of these mkdir could be avoided at the cost of another layer of dependencies: create rules for every target so that the parent directory is a pre-req target and have rules for directories to build them... that should put most of the the workload on make itself an limit drastically the number of mkdir... Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] patch for make to help in gbuild debugging
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 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 couldn't be run as built-in simple make commands anyway. Forget it. Yeah, but maybe there is something to be investigated to avoid fork when running recipies... I've read somewhere that spawn was much more performant than fork under cywin (note: I don;t know if make already do that or not, nor what are the implication...) Another thing: I think most of these mkdir could be avoided at the cost of another layer of dependencies: create rules for every target so that the parent directory is a pre-req target and have rules for directories to build them... that should put most of the the workload on make itself an limit drastically the number of mkdir... Another solution is a quick and dirty path to make to have ot try to create the base directory of a target before running a recipe for it. i don't like it because it will never be accepted upstream and would prevent building without a patched version... But since there is a platform/* support we could have conditional on windows to not do the mkdir if we have the 'right' make. (iow maintain the buidability with a vanilla make, but still improve perf when a 'lo-make' is available.) Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] patch for make to help in gbuild debugging
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 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 couldn't be run as
built-in simple make commands anyway. Forget it.
Yeah, but maybe there is something to be investigated to avoid fork
when running recipies... I've read somewhere that spawn was much more
performant than fork under cywin (note: I don;t know if make already
do that or not, nor what are the implication...)
Another thing: I think most of these mkdir could be avoided at the
cost of another layer of dependencies: create rules for every target
so that the parent directory is a pre-req target and have rules for
directories to build them... that should put most of the the workload
on make itself an limit drastically the number of mkdir...
Another solution is a quick and dirty path to make to have ot try to
create the base directory of a target before running a recipe for it.
something like
diff -r -u make-3.82/commands.c make-3.82-lo_trace/commands.c
--- make-3.82/commands.c2010-07-12 20:20:37.0 -0500
+++ make-3.82-lo_trace/commands.c 2011-06-27 13:48:40.0 -0500
@@ -437,6 +437,45 @@
}
}
^L
+static int _create_dirname(const char* name)
+{
+char buffer[PATH_MAX + 1];
+char* cursor;
+
+if(name == NULL)
+{
+return 0;
+}
+strncpy(buffer, name, PATH_MAX);
+buffer[PATH_MAX] = 0;
+cursor = buffer + strlen(buffer);
+while(cursor buffer)
+{
+if(*cursor == '/' || *cursor == '\\')
+{
+struct stat s;
+*cursor = 0;
+if(stat(buffer, s))
+{
+if(errno == ENOENT)
+{
+if(_create_dirname(buffer))
+{
+return -1;
+}
+return mkdir(buffer, 0777);
+}
+}
+else
+{
+return 0;
+}
+}
+cursor -= 1;
+}
+return -1;
+}
+
/* Execute the commands to remake FILE. If they are currently executing,
return or have already finished executing, just return. Otherwise,
fork off a child process to run the first command line in the sequence. */
@@ -446,6 +485,7 @@
{
const char *p;
+ _create_dirname(file-name);
/* Don't go through all the preparations if
the commands are nothing but whitespace. */
Note: this need hardening on windows to deal with C:\ and //xxx stuf
and possibly with /./ or /../ in the path (I'm not sure they are
possible at that stage of make)
Norbert
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] patch for make to help in gbuild debugging
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 something... so don't hold your breath. Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] patch for make to help in gbuild debugging
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
[Libreoffice] patch for make to help in gbuild debugging
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 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=a4f03f17f42ded70e6a3c49cf4e9a90eaf3c12ca Tor, note that this is v2 (i.e different from the one I pastebined you yesterday) Norbert Things look like this excerpt of make --debug=e,c on sw [...] ### 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 for call $(gb_Library_set_include) is ' -I/lo/libo/clone/writer/sw/source/core/inc -I/lo/libo/clone/writer/sw/source/ui/inc -I/lo/libo/clone/writer/sw/source/filter/inc -I/lo/libo/clone/writer/sw/inc/pch -I/lo/libo/clone/writer/sw/inc -I/lo/libo/solver/340/unxlngx6.pro/workdir/inc/sw/sdi -I/lo/libo/solver/340/unxlngx6.pro/workdir/Misc/sw/ $(INCLUDE) -I/lo/libo/solver/340/unxlngx6.pro/inc/offuh -I/lo/libo/solver/340/unxlngx6.pro/inc/sw ' ### call $(gb_Library_get_linktargetname) -- ### arg 0 for call $(gb_Library_get_linktargetname) is 'gb_Library_get_linktargetname' ### arg 1 for call $(gb_Library_get_linktargetname) is 'msword' ### arg 2 for call $(gb_Library_get_linktargetname) is implicit ### call $(gb_Library_get_filename) -- ### arg 0 for call $(gb_Library_get_filename) is 'gb_Library_get_filename' ### arg 1 for call $(gb_Library_get_filename) is 'msword' ### arg 2 for call $(gb_Library_get_filename) is implicit ### call to $(gb_Library_get_filename) expended into libmswordlo.so ### call $(gb_Library_get_filename) -- ### call to $(gb_Library_get_linktargetname) expended into Library/libmswordlo.so ### call $(gb_Library_get_linktargetname) -- ### call $(gb_LinkTarget_set_include) -- ### arg 0 for call $(gb_LinkTarget_set_include) is 'gb_LinkTarget_set_include' ### arg 1 for call $(gb_LinkTarget_set_include) is 'Library/libmswordlo.so' ### arg 2 for call $(gb_LinkTarget_set_include) is ' -I/lo/libo/clone/writer/sw/source/core/inc -I/lo/libo/clone/writer/sw/source/ui/inc -I/lo/libo/clone/writer/sw/source/filter/inc -I/lo/libo/clone/writer/sw/inc/pch -I/lo/libo/clone/writer/sw/inc -I/lo/libo/solver/340/unxlngx6.pro/workdir/inc/sw/sdi -I/lo/libo/solver/340/unxlngx6.pro/workdir/Misc/sw/ $(INCLUDE) -I/lo/libo/solver/340/unxlngx6.pro/inc/offuh -I/lo/libo/solver/340/unxlngx6.pro/inc/sw ' ### arg 3 for call $(gb_LinkTarget_set_include) is '' ### call $(gb_LinkTarget_get_headers_target) -- ### arg 0 for call $(gb_LinkTarget_get_headers_target) is 'gb_LinkTarget_get_headers_target' ### arg 1 for call $(gb_LinkTarget_get_headers_target) is 'Library/libmswordlo.so' ### arg 2 for call $(gb_LinkTarget_get_headers_target) is implicit ### arg 3 for call $(gb_LinkTarget_get_headers_target) is implicit ### call to $(gb_LinkTarget_get_headers_target) expended into /lo/libo/solver/340/unxlngx6.pro/workdir/Headers/Library/libmswordlo.so ### call $(gb_LinkTarget_get_headers_target) -- ### call $(gb_LinkTarget_get_target) -- ### arg 0 for call $(gb_LinkTarget_get_target) is 'gb_LinkTarget_get_target' ### arg 1 for call $(gb_LinkTarget_get_target) is 'Library/libmswordlo.so' ### arg 2 for call $(gb_LinkTarget_get_target) is implicit ### arg 3 for call $(gb_LinkTarget_get_target) is implicit ### call to $(gb_LinkTarget_get_target) expended into /lo/libo/solver/340/unxlngx6.pro/workdir/LinkTarget/Library/libmswordlo.so ### call $(gb_LinkTarget_get_target) -- ### call $(gb_LinkTarget_get_dep_target) -- ### arg 0 for call $(gb_LinkTarget_get_dep_target) is 'gb_LinkTarget_get_dep_target' ### arg 1 for call $(gb_LinkTarget_get_dep_target) is 'Library/libmswordlo.so' ### arg 2 for call $(gb_LinkTarget_get_dep_target) is implicit ### arg 3 for call $(gb_LinkTarget_get_dep_target) is implicit ### call to $(gb_LinkTarget_get_dep_target) expended into /lo/libo/solver/340/unxlngx6.pro/workdir/Dep/LinkTarget/Library/libmswordlo.so.d ### call $(gb_LinkTarget_get_dep_target) -- ### call to $(gb_LinkTarget_set_include) expended into /lo/libo/solver/340/unxlngx6.pro/workdir/Headers/Library/libmswordlo.so /lo/libo/solver/340/unxlngx6.pro/workdir/LinkTarget/Library/libmswordlo.so : INCLUDE := -I/lo/libo/clone/writer/sw/source/core/inc -I/lo/libo/clone/writer/sw/source/ui/inc -I/lo/libo/clone/writer/sw/source/filter/inc -I/lo/libo/clone/writer/sw/inc/pch -I/lo/libo/clone/writer/sw/inc -I/lo/libo/solver/340/unxlngx6.pro/workdir/inc/sw/sdi -I/lo/libo/solver/340/unxlngx6.pro/workdir/Misc/sw/ $(INCLUDE)
Re: [Libreoffice] patch for make to help in gbuild debugging
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 That add trace about, respectively, $(eval and $(scall see: http://cgit.freedesktop.org/libreoffice/contrib/dev-tools/commit/?id=a4f03f17f42ded70e6a3c49cf4e9a90eaf3c12ca Can we get that up-stream into make, like my glob speedup ? do you want me to fwd your patch to the list [ which is hard to interact with sadly - Reply-To: mangling and low traffic ;-]. ATB, Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] patch for make to help in gbuild debugging
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/dev-tools/commit/?id=a4f03f17f42ded70e6a3c49cf4e9a90eaf3c12ca looks good to me -- upstreaming it to the gnu project would be great. Oh fantastic! Until I looked more closely, I didn't realize this was a modification to Make itself. Brilliant. Seconded, thirded, etc.: *please* send this patch upstream, as I've a few projects with which I would appreciate having this functionality. Clearly, you're not the only one for whom this will solve a problem. Thank you! Kevin ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] patch for make to help in gbuild debugging
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. Nice :-) 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=a4f03f17f42ded70e6a3c49cf4e9a90eaf3c12ca Can we get that up-stream into make, like my glob speedup ? do you want me to fwd your patch to the list [ which is hard to interact with sadly - Reply-To: mangling and low traffic ;-]. Doesn't FSF require paperwork ? I looked at the make project page on savanah, but that was less than helpful. on that topic. the web-base thing to submit patch seems to be a patch graveyard more than anything else... But sure, I don't mind having it upstream at all... I did not mentioned it in the patch itself... but GPLv3+ Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] patch for make to help in gbuild debugging
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 see: http://cgit.freedesktop.org/libreoffice/contrib/dev-tools/commit/?id=a4f03f17f42ded70e6a3c49cf4e9a90eaf3c12ca Can we get that up-stream into make, like my glob speedup ? do you wantme to fwd your patch to the list [ which is hard to interact with sadly - Reply-To: mangling and low traffic ;-]. Doesn't FSF require paperwork ? I looked at the make project page on savanah, but that was less than helpful. on that topic. I don't think so, and I've yet to find any text suggesting so. A perhaps telling snippet From RMS' blog: It is up to you which of these activities to permit, but here are the FSF's recommendations. If you plan to make major contributions to the project, insist that the contribution agreement require that software versions including your contributions be available to the public under a free software license. This will allow the developer to sell exceptions, but prevent it from using your contributions in software that is only available under a proprietary license. If your contributions are smaller, you could accept a weaker condition that the company make your contributions available in a free software release as well as possibly in nonfree programs. This would allow the company to use your contributions in modified software that's only available under a proprietary license. Releasing proprietary software is never a good thing, but if your changes are smaller, it might be more important to improve the free version than resist the nonfree versions. -- http://www.fsf.org/blogs/rms/assigning-copyright My guess is that if the Make maintainers wanted to incorporate your code, as long as it's under GPLv3+, then they would accept it. Of note, here is a GNU Make news item (circa 2007) http://savannah.gnu.org/forum/forum.php?forum_id=4932 the web-base thing to submit patch seems to be a patch graveyard more than anything else... That's a different issue. If the maintainers have lost interest, then ... Cheers, Kevin ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] patch for make to help in gbuild debugging
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 for call $(gb_Library_set_include) is ' -I/lo/libo/clone/writer/sw/source/core/inc -I/lo/libo/clone/writer/sw/source/ui/inc -I/lo/libo/clone/writer/sw/source/filter/inc -I/lo/libo/clone/writer/sw/inc/pch -I/lo/libo/clone/writer/sw/inc -I/lo/libo/solver/340/unxlngx6.pro/workdir/inc/sw/sdi -I/lo/libo/solver/340/unxlngx6.pro/workdir/Misc/sw/ $(INCLUDE) -I/lo/libo/solver/340/unxlngx6.pro/inc/offuh -I/lo/libo/solver/340/unxlngx6.pro/inc/sw ' Perhaps just put it all on a single line, with newlines in arguments represented as \n, and long arguments just truncated at some suitably shortish length? Something like: ### $(gb_Library_set_include 'gb_Library_set_include'. 'msword', '\n-I/lo/libo/clone/writer/sw/source/core/inc\n...') But yeah, this is bikeshedding, certainly already what you have will be of great help in debugging gbuild issues. --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] patch for make to help in gbuild debugging
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 'gb_Library_set_include' ### arg 1 for call $(gb_Library_set_include) is 'msword' ### arg 2 for call $(gb_Library_set_include) is ' -I/lo/libo/clone/writer/sw/source/core/inc -I/lo/libo/clone/writer/sw/source/ui/inc -I/lo/libo/clone/writer/sw/source/filter/inc -I/lo/libo/clone/writer/sw/inc/pch -I/lo/libo/clone/writer/sw/inc -I/lo/libo/solver/340/unxlngx6.pro/workdir/inc/sw/sdi -I/lo/libo/solver/340/unxlngx6.pro/workdir/Misc/sw/ $(INCLUDE) -I/lo/libo/solver/340/unxlngx6.pro/inc/offuh -I/lo/libo/solver/340/unxlngx6.pro/inc/sw ' Perhaps just put it all on a single line, with newlines in arguments represented as \n, and long arguments just truncated at some suitably shortish length? Something like: ### $(gb_Library_set_include 'gb_Library_set_include'. 'msword', '\n-I/lo/libo/clone/writer/sw/source/core/inc\n...') But yeah, this is bikeshedding, certainly already what you have will be of great help in debugging gbuild issues. There are 2 reasons I did not do that 1/ readability. sometimes each individual argument is quite long and complex in it's own right and contain ',' and there can be sometime 6 or more such argument in one call. Parsing the arguments boundary could be painful. 2/ trying to keep the patch a simple and non-intrusive as I could. that is: do not add more loops than there already is and do _not_ do any extra allocation/copy/free (which prevent for instance substituting actual \n with \\n ) Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
