bug#7403: Unused variable `$source' in the depcomp script?
* Stefano Lattarini wrote on Mon, Nov 15, 2010 at 01:03:04AM CET: $ grep '\source\' lib/depcomp source Source file read by `PROGRAMS ARGS'. if test -z $depmode || test -z $source || test -z $object; then echo depcomp: Variables source, object and depmode must be set 12 # the object too, otherwise makedepend will parse it as a source file. Does this mean that the `$source' variable is really not required by depcomp, or am I missing something? It seems that $source is indeed not required. I'd still be wary of removing it: users might have modified depcomp scripts which use the variable. Yes, I consider that public API, documented in 'depcomp --help', and with example usage in the manual. In a sort of transposed way, there are packages using depcomp (plus some custom macros) which do not use Automake; we should not break them either. Thanks, Ralf
bug#7451: Better name for $(AM_V_at)?
From the automake manual, section on the silent-rules option: ``You can use the predefined variable $(AM_V_GEN) as a prefix to commands that should output a status line in silent mode, and $(AM_V_at) as a prefix to commands that should not output anything in silent mode. When output is to be verbose, both of these variables will expand to the empty string.'' Could we find a better name than $(AM_V_at)? - $(AM_V_SILENT) is nice, but also a bit too long. I wouldn't mind, but some people dislike long names for often-used variables. - $(SILENT) is shorter, but too much invasive of the user namespace. I'd strongly advise against it. - Other suggestions? If we find such a better name, we should then deprecate $(AM_V_at), but *not* remove it: it should be kept for backward-compatibility (probably for quite a long time). See also this older thread http://lists.gnu.org/archive/html/bug-automake/2010-04/msg1.html Regards, Stefano
bug#7403: Unused variable `$source' in the depcomp script?
tags 7403 wontfix close 7403 * Stefano Lattarini wrote on Sat, Nov 20, 2010 at 02:10:41PM CET: Makes sense. You can close the bug if you want (maybe with tag wontfix?) You can also do that yourself if you like. Just put control at debbugs in Bcc: for commands like above. Cheers, Ralf
Re: [RFC] Docs: document silent make rules in a new chapter
* Stefano Lattarini wrote on Thu, Nov 18, 2010 at 09:22:48PM CET:
On Thursday 18 November 2010, Nick Bowler wrote:
On 2010-11-18 20:31 +0100, Stefano Lattarini wrote:
+...@vindex @code{AM_V_GEN}
+...@c FIXME: wouldn't $(AM_V_SILENT) be clearer? Should we deprecate
+...@c $(AM_V_at)? It should be kept for backward-compatibility, of
+...@c course.
AM_V_GEN is a long enough name as it is; AM_V_SILENT would be even worse
in this regard.
AM_V_at is very useful for targets which have multiple commands. It's
not that interesting to see GEN foo.bar five times in a row.
There's probably a misunderstanding here; I was suggesting to rename
`AM_V_at' to `AM_V_SILENT', for clarity; and deprecate *only* the old
name `AM_V_at'. Does my proposal make sense now?
It makes sense, but it's a long name. It's a close call I'd say but
I wouldn't want to deprecate AM_V_at, simply because it is shorter.
Other renaming suggestions have been made before, see e.g. this thread:
http://lists.gnu.org/archive/html/bug-automake/2010-04/msg1.html
But I'm quite hesitant to do any renames at all unless there is a clear
advantage. Automake has had a slightly bad reputation in the past for
not being backward compatible, and I wouldn't want that to return. (And
I don't like overly verbose makefiles with lots of duplication either.)
Cheers,
Ralf
libtool --help: honor $AUTOCONF, $AUTOMAKE
I came across an interesting bug: the perl coverage output for a full
run of the Automake test suite was showing a single invocation of the
installed automake program, rather than the uninstalled
$builddir/tests/automake-1.11a
which should have been run.
Some tracking revealed that this happened in automake/tests/subobj9.test
which looks innocent enough. Turns out that it comes from './libtool
--help' which tries to be helpful in printing some 'automake --version'
output. This is flawed for a couple of reasons: the automake command at
the time './libtool --help' is run may be unrelated to the automake used
for bootstrapping the package; also, the user may have wanted to use an
override by setting $AUTOMAKE.
Now, the issue could be fixed with the two patches below, to Libtool and
Automake, respectively. Question is whether we could do better than
that:
In Libtool, getopt.m4sh is used for the libtoolize and libtool scripts.
For libtoolize, it seems appropriate to do as below. For libtool, the
best answer would be the Autoconf and Automake versions used to
bootstrap the package that created this particular libtool script.
Comments before I apply?
Thanks,
Ralf
Avoid running installed automake from 'libtool --help'.
* tests/subobj9.test: Export AUTOCONF and AUTOMAKE.
Together with fixed Libtool, this fixes check-coverage to not
invoke installed automake.
diff --git a/tests/subobj9.test b/tests/subobj9.test
index 2045d58..83f3a31 100755
--- a/tests/subobj9.test
+++ b/tests/subobj9.test
@@ -64,6 +64,9 @@ $AUTOMAKE -a
# Skip this test on configure errors (e.g., broken C++ compilers).
./configure || Exit 77
+# Ensure './libtool --help' will use the right tool versions.
+export AUTOCONF AUTOMAKE
+
# Opportunistically check that --tag=CXX is used when supported.
if ./libtool --help | grep tag=TAG; then
$MAKE print stdout || { cat stdout; Exit 1; }
Honor $AUTOCONF, $AUTOMAKE in --help output.
* libltdl/config/getopt.m4sh (func_help): Use $AUTOCONF and
$AUTOMAKE if set, for --version outout.
diff --git a/libltdl/config/getopt.m4sh b/libltdl/config/getopt.m4sh
index 2196743..e9363bc 100644
--- a/libltdl/config/getopt.m4sh
+++ b/libltdl/config/getopt.m4sh
@@ -592,8 +592,8 @@ func_help ()
s*\$LTCFLAGS*'$LTCFLAGS'*
s*\$LD*'$LD'*
s/\$with_gnu_ld/'$with_gnu_ld'/
- s/\$automake_version/'`(automake --version) 2/dev/null |$SED 1q`'/
- s/\$autoconf_version/'`(autoconf --version) 2/dev/null |$SED 1q`'/
+ s/\$automake_version/'`(${AUTOMAKE-automake} --version) 2/dev/null
|$SED 1q`'/
+ s/\$autoconf_version/'`(${AUTOCONF-autoconf} --version) 2/dev/null
|$SED 1q`'/
p
d
}
Re: [PATCH] {maint} Improve and extend tests on de-ansification support.
* Stefano Lattarini wrote on Tue, Nov 16, 2010 at 12:15:12AM CET: On Monday 15 November 2010, Ralf Wildenhues wrote: Well then we should adjust maintainer-check to not complain. Either way, maintainer-check results should not deteriorate. I'm not keen on meddling with the current maintainer-check rules, which are already quite hackish and not very easy to extend IMHO. ;-) So I'd like to seize this opportunity to push again my patch on a re-implementation of maintainer-check (in perl), which offers easy whitelisting of false positives, and more flexibility in pre-processing the input lines (which can be useful in case of more complex checks): http://lists.gnu.org/archive/html/automake-patches/2010-07/msg00084.html Gnulib has a few more facilities in this area, and several GNU projects use them already. It would be good if we worked toward common facilities here, rather than diverging more from it. Besides, I kinda dislike using perl where sed would suffice. Yes, I'm probably being selfish and stubborn on this one ... Another nit at cited patch of yours is that makefile rules run in parallel, the perl script tests don't. This helps speed, but also allows me to choose between stopping on first error or not (make -k). Thanks, Ralf
Re: [PATCH] {master} release-stats: account for generated `instspc-*.test' tests.
On Saturday 20 November 2010, Ralf Wildenhues wrote: * Stefano Lattarini wrote on Fri, Nov 19, 2010 at 09:18:33PM CET: I've realized that my patch on instspc.test split refactoring has broken the release-stats target, since now there are other generated tests besides the `*-p.test' tests. The attached patch fix this glitch in a quick dirty way; a better fix would probably involve a refactoring of the whole release-stats target, but that can be done later IMHO. So, OK to apply the attached patch to a temporary branch based off of commit `v1.11-395-ge118126' Overhauled and modularized tests in `instspc.test'., and merge to master? This will break again when we add the next set of generated tests. True. That's why in the refactoring I have in mind we would define a new variable `$(generated_tests)' in tests/Makefile.am, and fetch its value from top-level Makefile. How about determining them by grepping the test source for 'GENERATED AUTOMATICALLY' in the test source? That might be a bit fragile too in the long run, but it's definitely better than my hack in the short run. So I'll make the change. Thanks, Stefano
Re: [PATCH] {master} release-stats: account for generated `instspc-*.test' tests.
I pushed this: -*-*-*- release-stats: account for more generated tests. * Makefile.am (release-stats): Be sure to take into account all the generated tests, by grepping the test scripts to decide which ones of them are automatically generated. --- ChangeLog |7 +++ Makefile.am |2 +- Makefile.in |2 +- 3 files changed, 9 insertions(+), 2 deletions(-) diff --git a/ChangeLog b/ChangeLog index 2d0a145..fddb01f 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,10 @@ +2010-11-20 Stefano Lattarini stefano.lattar...@gmail.com + + release-stats: account for more generated tests. + * Makefile.am (release-stats): Be sure to take into account all + the generated tests, by grepping the test scripts to decide which + ones of them are automatically generated. + 2010-11-03 Stefano Lattarini stefano.lattar...@gmail.com Overhauled and modularized tests in `instspc.test'. diff --git a/Makefile.am b/Makefile.am index a5df109..1dec51e 100644 --- a/Makefile.am +++ b/Makefile.am @@ -658,7 +658,7 @@ release-stats: ps if test . != '$(srcdir)'; then tests=$$tests $(srcdir)/tests/*.test; \ else :; fi \ t=`ls -1 $$tests | wc -l` \ - tgen=`ls -1 $$tests | grep '.-p\.test' | wc -l` \ + tgen=`grep 'GENERATED AUTOMATICALLY' $$tests | wc -l` \ today=`date +%Y-%m-%d` \ echo add this to the table in doc/automake.texi after verification: \ printf '@item %s @tab %-6s @tab %4d @tab %4d @tab %4d @tab %4d %-4s @tab %4d %-4s @tab %3d @tab %d %-4s\n' \ diff --git a/Makefile.in b/Makefile.in index d9cff86..a721fce 100644 --- a/Makefile.in +++ b/Makefile.in @@ -1334,7 +1334,7 @@ release-stats: ps if test . != '$(srcdir)'; then tests=$$tests $(srcdir)/tests/*.test; \ else :; fi \ t=`ls -1 $$tests | wc -l` \ - tgen=`ls -1 $$tests | grep '.-p\.test' | wc -l` \ + tgen=`grep 'GENERATED AUTOMATICALLY' $$tests | wc -l` \ today=`date +%Y-%m-%d` \ echo add this to the table in doc/automake.texi after verification: \ printf '@item %s @tab %-6s @tab %4d @tab %4d @tab %4d @tab %4d %-4s @tab %4d %-4s @tab %3d @tab %d %-4s\n' \ -- 1.7.1 -*-*-*- Regards, Stefano
Re: [PATCH 0/2] {master} Remove long-deprecated `--output-dir' automake option.
On Saturday 20 November 2010, Ralf Wildenhues wrote: * Stefano Lattarini wrote on Thu, Nov 18, 2010 at 06:29:57PM CET: On Thursday 18 November 2010, Stefano Lattarini wrote: The `--output-dir' option of automake has been deprecated since versions 1.6.1 and 1.7, but then never removed. Oh, and I forgot to report that google codesearch cannot find any modern relevant use of the option: http://www.google.com/codesearch?hl=ensa=Nq=automake+output-dir http://www.google.com/codesearch?hl=ensa=Nq=output-dir+lang:automake This message is what saved you. ;-) Eh Eh :-) This time I had checked before writing the patch, but then I forgot to report that in my mail. OK for master. Applied, merged, and pushed. Thanks, Stefano
Re: [RFC] Docs: document silent make rules in a new chapter
On Saturday 20 November 2010, Ralf Wildenhues wrote:
* Stefano Lattarini wrote on Thu, Nov 18, 2010 at 09:22:48PM CET:
On Thursday 18 November 2010, Nick Bowler wrote:
On 2010-11-18 20:31 +0100, Stefano Lattarini wrote:
+...@vindex @code{AM_V_GEN}
+...@c FIXME: wouldn't $(AM_V_SILENT) be clearer? Should we deprecate
+...@c $(AM_V_at)? It should be kept for backward-compatibility, of
+...@c course.
AM_V_GEN is a long enough name as it is; AM_V_SILENT would be even worse
in this regard.
AM_V_at is very useful for targets which have multiple commands. It's
not that interesting to see GEN foo.bar five times in a row.
There's probably a misunderstanding here; I was suggesting to rename
`AM_V_at' to `AM_V_SILENT', for clarity; and deprecate *only* the old
name `AM_V_at'. Does my proposal make sense now?
It makes sense, but it's a long name. It's a close call I'd say but
I wouldn't want to deprecate AM_V_at, simply because it is shorter.
Other renaming suggestions have been made before, see e.g. this thread:
http://lists.gnu.org/archive/html/bug-automake/2010-04/msg1.html
But I'm quite hesitant to do any renames at all unless there is a clear
advantage. Automake has had a slightly bad reputation in the past for
not being backward compatible, and I wouldn't want that to return.
In this case that shouldn't be a problem, since I'm not proposing to
remove AM_V_at, but only to deprecate it in favor of the new alternative.
Anyway ...
(And I don't like overly verbose makefiles with lots of
duplication either.)
... I'm fine with this; I'll just rewrite the fixme comment to
reference the thread above and to be more possibilist:
@c FIXME: Could we find a better name than $(AM_V_at)? $(AM_V_SILENT)
@c is nice, but also a bit too long.
@c If we find such a better name, we should then deprecate $(AM_V_at),
@c but *not* remove it: it should be kept for backward-compatibility.
Thanks,
Stefano
Re: [PATCH 4/5] Tests defs: avoid some useless subshells.
* Stefano Lattarini wrote on Mon, Nov 15, 2010 at 06:26:05PM CET: * tests/defs: In the loop on $required tools: avoid subshells where not neded. OK except for the last hunk: --- a/tests/defs +++ b/tests/defs @@ -297,12 +297,12 @@ do *) # Generic case: the tool must support --version. echo $me: running $tool --version - ( $tool --version ) || exit 77 + $tool --version || exit 77 It is not likely but possible that $tool is a special builtin, in which case the shell is allowed to exit after an error. Please leave the subshell here. ;; esac done Thanks, Ralf
Re: [PATCH 5/5] Tests required tools: also try `-v' option for GNU compilers.
* Stefano Lattarini wrote on Mon, Nov 15, 2010 at 06:27:43PM CET: * tests/defs.in: In the loop on $required tools, for gcc and g++, also run gcc -v (resp. g++ -v), to get more information, and for consistency with gcj. Did this help you for anything in any way? Patch is OK. Thanks, Ralf
Re: [PATCH 0/5] More patches for the tests-init branch
* Stefano Lattarini wrote on Mon, Nov 15, 2010 at 06:18:15PM CET: Tests defs: don't let useless variables leak in test scripts. Tests defs: new subroutine `skip' for test skipping. Tests defs: some cleanup and minor fixes. No ticking clock for this patches at the moment; the clock will be started only after the current testsuite regressions have been solved. Patches (1) through (3) will have to wait until somebody has figured out why the *+#$)! /bin/sh on Tru64 exits upon set +e case `(set -o) 2/dev/null` in *posix*) set -o posix;; esac if 'set -e' has been called at some earlier point (leading to the instspc*test and probably other spurious test failures). Might be some internal shell data corruption, not sure. Cheers, Ralf
Re: [PATCH 4/5] Tests defs: avoid some useless subshells.
On Saturday 20 November 2010, Ralf Wildenhues wrote: * Stefano Lattarini wrote on Mon, Nov 15, 2010 at 06:26:05PM CET: * tests/defs: In the loop on $required tools: avoid subshells where not neded. OK except for the last hunk: --- a/tests/defs +++ b/tests/defs @@ -297,12 +297,12 @@ do *) # Generic case: the tool must support --version. echo $me: running $tool --version - ( $tool --version ) || exit 77 + $tool --version || exit 77 It is not likely but possible that $tool is a special builtin, in which case the shell is allowed to exit after an error. Please leave the subshell here. Good catch; I'll add a comment to explain why the subshell is needed in this case. BTW, it's ok if I add also your name to the ChangeLog entry? Regards, Stefano
Re: [PATCH 5/5] Tests required tools: also try `-v' option for GNU compilers.
On Saturday 20 November 2010, Ralf Wildenhues wrote: * Stefano Lattarini wrote on Mon, Nov 15, 2010 at 06:27:43PM CET: * tests/defs.in: In the loop on $required tools, for gcc and g++, also run gcc -v (resp. g++ -v), to get more information, and for consistency with gcj. Did this help you for anything in any way? I dimly remember that it helped me with a botched g++ installation (installation I did by hand for testing purposes, and which I managed to mess up); but this happened more than a month ago (maybe even two), so I'm not really sure anymore. Sorry. Patch is OK. Thanks! Stefano
Re: [PATCH 0/5] More patches for the tests-init branch
On Saturday 20 November 2010, Ralf Wildenhues wrote: * Stefano Lattarini wrote on Mon, Nov 15, 2010 at 06:18:15PM CET: Tests defs: don't let useless variables leak in test scripts. Tests defs: new subroutine `skip' for test skipping. Tests defs: some cleanup and minor fixes. No ticking clock for this patches at the moment; the clock will be started only after the current testsuite regressions have been solved. Patches (1) through (3) will have to wait until somebody has figured out why the *+#$)! /bin/sh on Tru64 exits upon set +e case `(set -o) 2/dev/null` in *posix*) set -o posix;; esac if 'set -e' has been called at some earlier point (leading to the instspc*test and probably other spurious test failures). Might be some internal shell data corruption, not sure. Wild guess: what about this? case `(set -o) 2/dev/null` in *posix*) set -o posix;; *) :;; esac Anyway, in the long run, I think it would be simpler and more reliable to run the tests with configure-detected $SHELL, and add proper configure checks to reject overly buggy shells. The pending patch of mine Testsuite: use $SHELL to run tests which are shell scripts: http://lists.gnu.org/archive/html/automake-patches/2010-09/msg00022.html can help with this (it implements the fist step). Regards, Stefano
Re: [PATCH 4/5] Tests defs: avoid some useless subshells.
* Stefano Lattarini wrote on Sat, Nov 20, 2010 at 02:14:57PM CET: On Saturday 20 November 2010, Ralf Wildenhues wrote: * Stefano Lattarini wrote on Mon, Nov 15, 2010 at 06:26:05PM CET: # Generic case: the tool must support --version. echo $me: running $tool --version - ( $tool --version ) || exit 77 + $tool --version || exit 77 It is not likely but possible that $tool is a special builtin, in which case the shell is allowed to exit after an error. Please leave the subshell here. Good catch; I'll add a comment to explain why the subshell is needed in this case. Good idea. BTW, it's ok if I add also your name to the ChangeLog entry? Sure, if you like, but I didn't really contribute all that much to this patch. :-P Cheers, Ralf
maintainer checks (was: Re: [PATCH] {maint} Improve and extend tests on de-ansification support.)
On Saturday 20 November 2010, Ralf Wildenhues wrote: * Stefano Lattarini wrote on Tue, Nov 16, 2010 at 12:15:12AM CET: On Monday 15 November 2010, Ralf Wildenhues wrote: Well then we should adjust maintainer-check to not complain. Either way, maintainer-check results should not deteriorate. I'm not keen on meddling with the current maintainer-check rules, which are already quite hackish and not very easy to extend IMHO. ;-) So I'd like to seize this opportunity to push again my patch on a re-implementation of maintainer-check (in perl), which offers easy whitelisting of false positives, and more flexibility in pre-processing the input lines (which can be useful in case of more complex checks): http://lists.gnu.org/archive/html/automake-patches/2010-07/msg00084.html Gnulib has a few more facilities in this area, and several GNU projects use them already. Do these facilities allow whitelisting at least at the file:line level? Do they allow whitelisting through (possibly file-specific) regexps? If yes, then I agree that we should use them instead of diverging more and add more code duplication. If not, they are not flexible enough IMHO. It would be good if we worked toward common facilities here, rather than diverging more from it. Besides, I kinda dislike using perl where sed would suffice. But it does not suffice, unless you can think of an easy way to do the whitelisting described above with grep+sed (personally, I can't). Yes, I'm probably being selfish and stubborn on this one ... ;-) Another nit at cited patch of yours is that makefile rules run in parallel, the perl script tests don't. ATM, the time required to run all the maintchecks is low enough that this is not a problem. And IMHO we can always optimize later if speed becomes a problem. This helps speed, but also allows me to choose between stopping on first error or not (make -k). My perl script never stops at the first error: I saw no reason to allow such a behaviour. But I think we could easily enhance the script to make that configurable, if it's desiderable. It's still just an RFC after all. BTW, a much more serious limitation of my script is that it currently doesn't work in VPATH builds -- which is unacceptable. Suggestions about how to fix that without complicating the script too much are very welcome. Regards, Stefano
Re: [RFC] Docs: document silent make rules in a new chapter
* Stefano Lattarini wrote on Thu, Nov 18, 2010 at 09:22:48PM CET:
On Thursday 18 November 2010, Nick Bowler wrote:
On 2010-11-18 20:31 +0100, Stefano Lattarini wrote:
+...@vindex @code{AM_V_GEN}
+...@c FIXME: wouldn't $(AM_V_SILENT) be clearer? Should we deprecate
+...@c $(AM_V_at)? It should be kept for backward-compatibility, of
+...@c course.
AM_V_GEN is a long enough name as it is; AM_V_SILENT would be even worse
in this regard.
AM_V_at is very useful for targets which have multiple commands. It's
not that interesting to see GEN foo.bar five times in a row.
There's probably a misunderstanding here; I was suggesting to rename
`AM_V_at' to `AM_V_SILENT', for clarity; and deprecate *only* the old
name `AM_V_at'. Does my proposal make sense now?
It makes sense, but it's a long name. It's a close call I'd say but
I wouldn't want to deprecate AM_V_at, simply because it is shorter.
Other renaming suggestions have been made before, see e.g. this thread:
http://lists.gnu.org/archive/html/bug-automake/2010-04/msg1.html
But I'm quite hesitant to do any renames at all unless there is a clear
advantage. Automake has had a slightly bad reputation in the past for
not being backward compatible, and I wouldn't want that to return. (And
I don't like overly verbose makefiles with lots of duplication either.)
Cheers,
Ralf
another perl coverage run
Hello automake list readers, Stefano asked for coverage information about Automake recently, so I triggered another 'make check-coverage' on my system, held hands of Devel::Cover a bit, waited a looong time, then collected the results. They are in a set of HTML pages roughly 500K size, the toplevel one is attached. Should I just commit them to the web server temporarily? Anybody have a better idea of where to store such data? Anyway, the logs show that there is one place in the build or test code where we call the installed automake rather than the one inside the build tree. This causes Devel::Cover to take into account all those installed perl modules from the installed Automake package, turning all the nice statistics about how good our coverage is way down, undeservedly. ;-) Patch coming up on -patches in a minute ... The summary also shows that apparently some files are not tracked correctly, for example DisjConditions.pm, although it is fully covered by the respective unit tests. I'm not yet sure how that happened. Cheers, Ralf
Re: another perl coverage run
On Saturday 20 November 2010, Ralf Wildenhues wrote: Hello automake list readers, Hi Ralf. Stefano asked for coverage information about Automake recently, so I triggered another 'make check-coverage' on my system, held hands of Devel::Cover a bit, waited a looong time, then collected the results. They are in a set of HTML pages roughly 500K size, the toplevel one is attached. The attached file results empty for me (by empty I relly mean 0 bytes long). Is anybody else experiencing this? Regards, Stefano
Re: another perl coverage run
* Ralf Wildenhues wrote on Sat, Nov 20, 2010 at 10:28:17AM CET: Stefano asked for coverage information about Automake recently, so I triggered another 'make check-coverage' on my system, held hands of Devel::Cover a bit, waited a looong time, then collected the results. They are in a set of HTML pages roughly 500K size, the toplevel one is attached. Hmm, the list server removes HTML attachments; that can only be a good thing in general. ;-) Here's a plain-text copy of the summary (sorry for the long lines): Coverage Summary Database: /tmp/build/cover_db file stmt bran cond subpodtime total /tmp/automake/lib/Automake/ChannelDefs.pm95.8 92.9 n/a 94.1 100.0 0.095.2 /tmp/automake/lib/Automake/Channels.pm 84.1 70.6 75.0 87.2 100.0 0.281.8 /tmp/automake/lib/Automake/Condition.pm 100.0 100.0 100.0 100.0 100.0 0.4100.0 /tmp/automake/lib/Automake/Configure_ac.pm 100.0 100.0 50.0 100.0 100.0 0.097.9 /tmp/automake/lib/Automake/DisjConditions.pm n/an/an/a n/an/an/an/a /tmp/automake/lib/Automake/FileUtils.pm 56.9 31.2 18.2 76.0 100.0 0.052.7 /tmp/automake/lib/Automake/General.pmn/an/an/a n/an/an/an/a /tmp/automake/lib/Automake/Item.pm n/an/an/a n/an/an/an/a /tmp/automake/lib/Automake/ItemDef.pmn/an/an/a n/an/an/an/a /tmp/automake/lib/Automake/Location.pm 67.3 n/a50.0 80.0 100.0 0.272.4 /tmp/automake/lib/Automake/Options.pm96.9 95.0 92.6 96.0 100.0 0.095.2 /tmp/automake/lib/Automake/Rule.pm 93.6 90.0 81.2 89.2 100.0 0.391.6 /tmp/automake/lib/Automake/RuleDef.pm100.0 n/an/a 100.0 100.0 0.0100.0 /tmp/automake/lib/Automake/Struct.pm 79.0 51.9 44.4 82.9 50.0 0.167.6 /tmp/automake/lib/Automake/VarDef.pm 97.6 83.3 100.0 100.0 100.0 0.196.9 /tmp/automake/lib/Automake/Variable.pm 95.7 87.0 84.5 96.4 100.0 0.592.7 /tmp/automake/lib/Automake/Version.pm100.0 100.0 100.0 100.0 100.0 0.0100.0 /tmp/automake/lib/Automake/Wrap.pm 100.0 100.0 100.0 100.0 100.0 0.1100.0 /tmp/automake/lib/Automake/XFile.pm 72.5 41.7 14.3 77.8 100.0 82.4 63.4 /tmp/automake/lib/Automake/tests/Cond2.pl100.0 n/an/a 100.0 n/a0.0100.0 /tmp/automake/lib/Automake/tests/Cond3.pl100.0 n/an/a 100.0 n/a0.0100.0 /tmp/automake/lib/Automake/tests/Condition-t.pl 75.0 50.0 33.3 100.0 n/a0.061.1 /tmp/automake/lib/Automake/tests/Condition.pl89.6 50.0 33.3 100.0 n/a0.075.2 /tmp/automake/lib/Automake/tests/DisjCon2.pl 100.0 n/an/a 100.0 n/a0.0100.0 /tmp/automake/lib/Automake/tests/DisjCon3.pl 100.0 n/an/a 100.0 n/a0.0100.0 /tmp/automake/lib/Automake/tests/DisjConditions-t.pl 75.0 50.0 33.3 100.0 n/a0.061.1 /tmp/automake/lib/Automake/tests/DisjConditions.pl 85.9 50.0 42.9 100.0 n/a0.072.1 /tmp/automake/lib/Automake/tests/Version.pl 68.4 64.3 100.0 100.0 n/a0.072.1 /tmp/automake/lib/Automake/tests/Version2.pl 100.0 n/an/a 100.0 n/a0.0100.0 /tmp/automake/lib/Automake/tests/Version3.pl 100.0 n/an/a 100.0 n/a0.0100.0 /tmp/automake/lib/Automake/tests/Wrap.pl 82.6 50.0 n/a 100.0 n/a0.080.0 /tmp/build/aclocal 97.8 94.5 73.6 97.5 n/a3.994.7 /tmp/build/automake 96.1 89.6 88.7 97.1 n/a1.293.5 /tmp/build/lib/Automake/Config.pm100.0 n/an/a 100.0 n/a0.0100.0 /usr/local/bin/autoheader83.2 47.4 58.3 100.0 n/a0.074.6 /usr/local/bin/autom4te 86.5 60.3 54.5 91.3 n/a4.477.4 /usr/local/bin/automake 11.9 1.40.2 23.0 n/a0.08.2 /usr/local/bin/autoupdate92.3 55.3 50.0 100.0 n/a0.083.1 /usr/local/share/autoconf/Autom4te/C4che.pm 100.0 66.7 66.7 100.0 100.0 0.094.4 /usr/local/share/autoconf/Autom4te/ChannelDefs.pm54.7 45.5 n/a 73.3 100.0 0.159.1 /usr/local/share/autoconf/Autom4te/Channels.pm 64.1 54.4 58.3 68.4 100.0 0.063.7
Re: [RFC] Docs: document silent make rules in a new chapter
On Saturday 20 November 2010, Ralf Wildenhues wrote:
* Stefano Lattarini wrote on Thu, Nov 18, 2010 at 09:22:48PM CET:
On Thursday 18 November 2010, Nick Bowler wrote:
On 2010-11-18 20:31 +0100, Stefano Lattarini wrote:
+...@vindex @code{AM_V_GEN}
+...@c FIXME: wouldn't $(AM_V_SILENT) be clearer? Should we deprecate
+...@c $(AM_V_at)? It should be kept for backward-compatibility, of
+...@c course.
AM_V_GEN is a long enough name as it is; AM_V_SILENT would be even worse
in this regard.
AM_V_at is very useful for targets which have multiple commands. It's
not that interesting to see GEN foo.bar five times in a row.
There's probably a misunderstanding here; I was suggesting to rename
`AM_V_at' to `AM_V_SILENT', for clarity; and deprecate *only* the old
name `AM_V_at'. Does my proposal make sense now?
It makes sense, but it's a long name. It's a close call I'd say but
I wouldn't want to deprecate AM_V_at, simply because it is shorter.
Other renaming suggestions have been made before, see e.g. this thread:
http://lists.gnu.org/archive/html/bug-automake/2010-04/msg1.html
But I'm quite hesitant to do any renames at all unless there is a clear
advantage. Automake has had a slightly bad reputation in the past for
not being backward compatible, and I wouldn't want that to return.
In this case that shouldn't be a problem, since I'm not proposing to
remove AM_V_at, but only to deprecate it in favor of the new alternative.
Anyway ...
(And I don't like overly verbose makefiles with lots of
duplication either.)
... I'm fine with this; I'll just rewrite the fixme comment to
reference the thread above and to be more possibilist:
@c FIXME: Could we find a better name than $(AM_V_at)? $(AM_V_SILENT)
@c is nice, but also a bit too long.
@c If we find such a better name, we should then deprecate $(AM_V_at),
@c but *not* remove it: it should be kept for backward-compatibility.
Thanks,
Stefano
Re: [RFC] Docs: document silent make rules in a new chapter
* Stefano Lattarini wrote on Sat, Nov 20, 2010 at 01:00:05PM CET: ... I'm fine with this; I'll just rewrite the fixme comment to reference the thread above and to be more possibilist: @c FIXME: Could we find a better name than $(AM_V_at)? $(AM_V_SILENT) @c is nice, but also a bit too long. @c If we find such a better name, we should then deprecate $(AM_V_at), @c but *not* remove it: it should be kept for backward-compatibility. Instead, please open a PR by writing to bug-automake, and point to the cited threads and this one. debbugs is better than a comment in the manual. Thanks, Ralf
Re: [RFC] Docs: document silent make rules in a new chapter
On Saturday 20 November 2010, Ralf Wildenhues wrote: * Stefano Lattarini wrote on Sat, Nov 20, 2010 at 01:00:05PM CET: ... I'm fine with this; I'll just rewrite the fixme comment to reference the thread above and to be more possibilist: @c FIXME: Could we find a better name than $(AM_V_at)? $(AM_V_SILENT) @c is nice, but also a bit too long. @c If we find such a better name, we should then deprecate $(AM_V_at), @c but *not* remove it: it should be kept for backward-compatibility. Instead, please open a PR by writing to bug-automake, and point to the cited threads and this one. debbugs is better than a comment in the manual. You're right of course. PR opened. Regards, Stefano
default -g ??!?
I have a FOSS project distributed by debian, and for quite I've been using this in the Makefile.am under install-data-am: -strip --strip-all $(bindir)/executable Since I could not find a way to prevent the project being built -g, and there is no need for this. However, I have a new release and my packager at debian is now saying they do not want strip used in makefiles. How can I prevent -g from being used? MK -- The angel of history[...]is turned toward the past. (Walter Benjamin)
Re: default -g ??!?
Hello, * MK wrote on Fri, Nov 19, 2010 at 08:10:25PM CET: Since I could not find a way to prevent the project being built -g, and there is no need for this. ./configure CFLAGS=-O2 See 'info Autoconf C Compiler'. For C++ use CXXFLAGS etc. Cheers, Ralf
Re: default -g ??!?
On 20/11/10 06:10, MK wrote: I have a FOSS project distributed by debian, and for quite I've been using this in the Makefile.am under install-data-am: -strip --strip-all $(bindir)/executable Since I could not find a way to prevent the project being built -g, and there is no need for this. Use dh_strip However, I have a new release and my packager at debian is now saying they do not want strip used in makefiles. How can I prevent -g from being used? The normal debian packages are stripped by dh_strip, or not when the debug-symbols debs are made. Therefore, the debian packager wants control over that. Therefore, you don't need to worry about stripping.
Re: default -g ??!?
Ah, it's because of GNU make: By default, the Make rules should compile and link with -g, so that executable programs have debugging symbols. Users who don't mind being helpless can strip the executables later if they wish. Nice, flexible software it ain't. This is an assbackward policy. The idea that general, non-programmer users will be helpless without debugging symbols is completely absurd. If and when you do need debugging symbols, it should be easy to opt *for* them. Instead, I am left with the choice of leaving them in by default, or having to use strip, making it impossible to add them. Maybe there is a way to do this via autoconf? -- The angel of history[...]is turned toward the past. (Walter Benjamin)
Re: default -g ??!?
Op 20 nov 2010, om 16:36 heeft MK het volgende geschreven: Maybe there is a way to do this via autoconf? Yes, you can place: CFLAGS= at the beginning of your configure.ac, after AM_INIT_AUTOMAKE but before AC_PROG_CC. This will prevent your configure from allowing user-specified CFLAGS overrides, but you will get what you want. Cheers -- k
Re: default -g ??!?
* Raphael 'kena' Poss wrote on Sat, Nov 20, 2010 at 04:47:00PM CET:
Op 20 nov 2010, om 16:36 heeft MK het volgende geschreven:
Maybe there is a way to do this via autoconf?
Yes, you can place:
CFLAGS=
at the beginning of your configure.ac, after AM_INIT_AUTOMAKE but before
AC_PROG_CC.
This will prevent your configure from allowing user-specified CFLAGS
overrides, but you will get what you want.
: ${CFLAGS=}
gets you both.
Re: default -g ??!?
On Sat, 20 Nov 2010 10:36:34 -0500 MK halfcountp...@intergate.com wrote: If and when you do need debugging symbols, it should be easy to opt *for* them. Instead, I am left with the choice of leaving them in by default, or having to use strip, making it impossible to add them. Sorry if that seemed like a rant. Anyway, I have managed to get that functionality by inserting this into the configure script from autoconf: CFLAGS=-O2 $CFLAGS Giving make a default to use if no flags are present, and also making it possible for the user to add CFLAGS=-g if they wish. Please excuse my ignorance and frustration ;) -- The angel of history[...]is turned toward the past. (Walter Benjamin)
Re: default -g ??!?
On Sat, Nov 20, 2010 at 10:36:34AM -0500, MK wrote: Ah, it's because of GNU make: By default, the Make rules should compile and link with -g, so that executable programs have debugging symbols. Users who don't mind being helpless can strip the executables later if they wish. Nice, flexible software it ain't. This is an assbackward policy. The idea that general, non-programmer users will be helpless without debugging symbols is completely absurd. What actual problems are the debugging symbols causing you? What is the wrong with the default? If and when you do need debugging symbols, it should be easy to opt *for* them. Instead, I am left with the choice of leaving them in by default, or having to use strip, making it impossible to add them. Automake already provides an install-strip target for just this purpose. Most users are unaware if they are running stripped or unstripped binaries, but when a user runs into problems, it's nice to have unstripped binaries around for diagnostic purposes. It's also contrary to the defaults, and what most people would expect, given that pretty much every other automake-using package does the opposite of what you want! For Debian at least, we want unstripped binaries by default. We'll do the stripping later. There is a reason for this. We provide -dbg packages, which nowadays contain detached debugging symbols. The dh_strip program handles this as already mentioned. In the future, we may end up taking a similar path to Ubuntu and automatically produce .ddebs (debug .deb packages) containing the stripped debug info for every single package built, or even allow direct download of symbols from a central database. Having unstripped binaries is contrary to all these goals. Note that this is not unique to Debian; all distributions want to have debug symbols for end-user diagnostics, and we don't want to ask the user to recompile with debug symbols enabled--they would then not be using the same binaries, which might not exhibit the same behaviour. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: another perl coverage run
Updated summary including the 'libtool --help' fixes, shortened file names, and without listing the installed files from Autoconf. The Total percentages still include them however. filestmt bran cond subpodtime total lib/Automake/ChannelDefs.pm 95.8 92.9 n/a94.1 100.0 0.0 95.2 lib/Automake/Channels.pm84.1 70.6 75.0 87.2 100.0 0.2 81.8 lib/Automake/Condition.pm 100.0 100.0 100.0 100.0 100.0 0.4 100.0 lib/Automake/Configure_ac.pm100.0 100.0 50.0 100.0 100.0 0.0 97.9 lib/Automake/DisjConditions.pm 94.7 100.0 n/a94.7 100.0 0.3 96.2 lib/Automake/FileUtils.pm 56.9 31.2 18.2 76.0 100.0 0.0 52.7 lib/Automake/General.pm 89.7 83.3 n/a100.0 0.00.0 88.6 lib/Automake/Item.pm100.0 50.0 66.7 100.0 100.0 0.3 94.8 lib/Automake/ItemDef.pm 100.0 n/an/a100.0 100.0 0.1 100.0 lib/Automake/Location.pm67.3 n/a50.0 80.0 100.0 0.2 72.4 lib/Automake/Options.pm 96.9 95.0 92.6 96.0 100.0 0.0 95.2 lib/Automake/Rule.pm93.6 90.0 81.2 89.2 100.0 0.3 91.6 lib/Automake/RuleDef.pm 100.0 n/an/a100.0 100.0 0.0 100.0 lib/Automake/Struct.pm 79.0 51.9 44.4 82.9 50.0 0.1 67.6 lib/Automake/VarDef.pm 97.6 83.3 100.0 100.0 100.0 0.1 96.9 lib/Automake/Variable.pm95.7 87.0 84.5 96.4 100.0 0.5 92.7 lib/Automake/Version.pm 100.0 100.0 100.0 100.0 100.0 0.0 100.0 lib/Automake/Wrap.pm100.0 100.0 100.0 100.0 100.0 0.1 100.0 lib/Automake/XFile.pm 72.5 41.7 14.3 77.8 100.0 81.9 63.4 lib/Automake/tests/Cond2.pl 100.0 n/an/a100.0 n/a0.0 100.0 lib/Automake/tests/Cond3.pl 100.0 n/an/a100.0 n/a0.0 100.0 lib/Automake/tests/Condition-t.pl 75.0 50.0 33.3 100.0 n/a0.0 61.1 lib/Automake/tests/Condition.pl 89.6 50.0 33.3 100.0 n/a0.0 75.2 lib/Automake/tests/DisjCon2.pl 100.0 n/an/a100.0 n/a0.0 100.0 lib/Automake/tests/DisjCon3.pl 100.0 n/an/a100.0 n/a0.0 100.0 lib/Automake/tests/DisjConditions-t.pl 75.0 50.0 33.3 100.0 n/a0.0 61.1 lib/Automake/tests/DisjConditions.pl85.9 50.0 42.9 100.0 n/a0.0 72.1 lib/Automake/tests/Version.pl 68.4 64.3 100.0 100.0 n/a0.0 72.1 lib/Automake/tests/Version2.pl 100.0 n/an/a100.0 n/a0.0 100.0 lib/Automake/tests/Version3.pl 100.0 n/an/a100.0 n/a0.0 100.0 lib/Automake/tests/Wrap.pl 82.6 50.0 n/a100.0 n/a0.0 80.0 aclocal 97.8 94.5 73.6 97.5 n/a3.7 94.7 automake96.1 89.6 88.7 97.1 n/a1.1 93.5 lib/Automake/Config.pm 100.0 n/an/a100.0 n/a0.0 100.0 Total 87.3 73.7 74.8 91.1 95.5 100.0 83.1
Re: default -g ??!?
On Sat, 20 Nov 2010 12:13:38 -0500 Paul Smith psm...@gnu.org wrote: This chapter has no relationship to any default BUILT INTO or REQUIRED by GNU make; in fact there IS NO default value for CFLAGS built into GNU make: Hmm, well it seems to via autotools. But since this is not inescapable (which is what I first took this to mean, not being a big make user), no big deal. Sorry again for over-reacting. Of course you can do what you like, but I should point out that the recommendations from the GNU people are the best practices resulting from decades of producing and using free software products. If I were you I'd take advantage of that experience. I have every respect for GNU, but the justification used in that document is just patronizing: implying that normal users will be left helpless or that it represents a devil-may-care attitude. I have been programming long enough to recognize that is someone's opinion, and not a general truth. Dare I say that presenting it so strongly is a little unprofessional? Justifications WRT to distro packaging issues, however, seem much more reasonable. However, my conundrum is that I do not think this is a good default for people who build from source: years ago, when I was a new linux user and used to build stuff from source a lot, I was in the habit of stip-all'ing. Now I only source build for particular things, and I suppose I got out of this habit for a while and forgot about it. So I was surprised this morning to recognize that most of the binaries in my /usr/local had debugging symbols! And after stripping *, I noticed that gvim loads much quicker, heh-heh. Point being: while users of the source can opt for this (if they know), it just seems like a bad policy to by default leave them with a product that needlessly wastes a considerable amount of memory and may not perform as well as it could. I believe most of my users do build from source (and often could be new to the process), so it is not very satisfying for me to add a note to the README, etc, in order to accommodate distro packaging. It seems to me that since the packagers *in general* should be considered more expert, the onus should be on them to ./configure CFLAGS=[our flags]. Obviously this is against the grain, but I do not really want to kowtow to a Goliath rules David type extortion whereby the distros say, your default build *must* contain debugging symbols. I suppose that might mean having to maintain a slightly different package just for them; no big deal, but still I think a poor compromise consequential of bad policy. MK -- The angel of history[...]is turned toward the past. (Walter Benjamin)
Re: default -g ??!?
On Sat, 20 Nov 2010 17:31:32 + Roger Leigh rle...@codelibre.net wrote: What actual problems are the debugging symbols causing you? What is the wrong with the default? I mention this in my other email (about gvim, and that a -g exe will load noticeably slower than one without debug symbols). I do not think the exception (a need for debugging) should make the rule (general use, production grade software). I'd bet 99%+ of the time those compiled in debugging symbols never even get used a single time. Yes, I know you can optionally strip, but again this is has the exception make the rule. It just ain't as user friendly that way. Most users are unaware if they are running stripped or unstripped binaries, but when a user runs into problems, it's nice to have unstripped binaries around for diagnostic purposes. So who cares that for who knows how long I have been tapping my fingers for 3-4 seconds waiting for my unstripped gvim to load?? I'd much, much rather have it work in as streamlined a manner day to day, *by default*, then if I run into a problem, I can build CFLAGS=-g to diagnose. If I put a device in your car that ran the battery down and lowered the gas mileage, the purpose of which was to diagnose problems *when there aren't any*, then said you should leave it on all the time anyway, what would you think? I understand the argument that by always using the -g version, you can avoid having complications whereby the exe compiled without debugging symbols may demonstrate problems the -g does not. However, by again letting this exception set the rule, you are condemning all software to run wastefully. For Debian at least, we want unstripped binaries by default. We'll do the stripping later. There is a reason for this. We provide -dbg packages, which nowadays contain detached debugging symbols. The dh_strip program handles this as already mentioned. Well, point taken, and certainly the stuff in my /usr/bin has been stripped by the distro. Terrific -- but as I said in the other email, this means you, the distro rep, are potentially setting policies for source built software (or forcing developers to maintain one for source downloads, one for debian, one for redhat, etc.) I have yet to discuss this with my packager, but if it is no good to say, Well, we're the experts here: is it so hard for you to add -g to CFLAGS when you package? because this would be incompatible with Debian systems or automation, then the Debian system has a design flaw in it, and someone saying to me just put a note in your README is, in effect, a work-around for *your* short sighted laziness (no offence intended). It's almost a form of imperialism, if you get my drift ;) How does it fit in with the GNU philosophy of user empowerment vs. proprietary policy making? Having unstripped binaries is contrary to all these goals. Note that this is not unique to Debian; Okay, so to stretch the analogy: one imperialist nation follows the example of another, so this justifies it? Methinks the emperor wears no clothes here. MK -- The angel of history[...]is turned toward the past. (Walter Benjamin)
Re: default -g ??!?
On Sat, 20 Nov 2010, MK wrote: Justifications WRT to distro packaging issues, however, seem much more reasonable. However, my conundrum is that I do not think this is a good default for people who build from source: years ago, when I was a new linux user and used to build stuff from source a lot, I was in the habit of stip-all'ing. Now I only source build for particular things, and I suppose I got out of this habit for a while and forgot about it. So I was surprised this morning to recognize that most of the binaries in my /usr/local had debugging symbols! And after stripping *, I noticed that gvim loads much quicker, heh-heh. The vast majority of Linux users install from binary packages, or via source-based install systems which assure that appropriate build options are applied. Very few build by hand and install under /usr/local. Those that do are likely to read the standard INSTALL file and therefore know what to do. Things are likely different for Plan 9 users due to substantially dimished support for binary packages for that OS. Since you found that gvim loads much quicker after it has been stripped, I must assume that you are using the Plan 9 OS rather than Linux. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: default -g ??!?
On Sat, 20 Nov 2010, MK wrote: I mention this in my other email (about gvim, and that a -g exe will load noticeably slower than one without debug symbols). I do not think the exception (a need for debugging) should make the rule (general use, production grade software). I'd bet 99%+ of the time those compiled in debugging symbols never even get used a single time. Under a normal operating system (i.e. perhaps not Plan 9, I am not sure) the debug symbols are separate from the executable text so that the OS will never read the debug symbol area while it is loading the program. This means that there should be no performance difference. Perhaps you have a problem with your system or should be using 'vim' rather than 'gvim'? Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: default -g ??!?
On Sat, 20 Nov 2010 14:17:14 -0600 (CST) Bob Friesenhahn bfrie...@simple.dallas.tx.us wrote: The vast majority of Linux users install from binary packages, or via source-based install systems which assure that appropriate build options are applied. Very few build by hand and install under /usr/local. True, but while I do not track binary downloads from debian, I do track source downloads from my site. Also, I get some feedback from users. Because versions of the project are currently in debian unstable and testing repos (which are necessary before it can be qualified stable), I am positive that *most* of my users are people who download and build from the source. Basically, I don't think source users should count as second class citizens here. Those that do are likely to read the standard INSTALL file and therefore know what to do. Maybe so, and maybe not. But regardless: it makes more sense to have the default *appropriate for general use*, rather for a distro packager (who's work I do appreciate!). Otherwise, I have to put a note in the INSTALL: To accommodate the constraints of distro package systems, you will have to use a configure option or strip your binaries if you do not want debugging symbols slowing you down. I know that historically, that has been the practice, and I am arguing against the grain. Since you found that gvim loads much quicker after it has been stripped, I must assume that you are using the Plan 9 OS rather than Linux. No, linux. I build vim because I have yet to see a distro package that is configured the way I want it (and no, the vim-everything packages do not actually contain everything). Generally I just use apt or yum, but for some particular things like this (or for projects such as my own, which are not available as binaries for every distro), I source build. Also, if you are using a small or offbeat linux distribution, there's surely a lot of software that simply is not available for it in binary, but that can easily be built from source. MK -- The angel of history[...]is turned toward the past. (Walter Benjamin)
Re: default -g ??!?
* MK wrote on Sat, Nov 20, 2010 at 09:55:51PM CET: Maybe so, and maybe not. But regardless: it makes more sense to have the default *appropriate for general use*, rather for a distro packager (who's work I do appreciate!). Otherwise, I have to put a note in the INSTALL: To accommodate the constraints of distro package systems, you will have to use a configure option or strip your binaries if you do not want debugging symbols slowing you down. Just tell them to 'make install-strip' rather than 'make install'. Please show numbers and glibc version to prove that your vim really loads slower when not stripped, you can use time vim -c :q the runtime loader does not map the debug sections so it should not have any impact. Besides, disk space is cheap nowadays, for excessive debug symbol sizes on sane systems like GNU/Linux one should file compiler/linker bugs. Cheers, Ralf
Re: default -g ??!?
On Sat, 20 Nov 2010 14:21:27 -0600 (CST) Bob Friesenhahn bfrie...@simple.dallas.tx.us wrote: Under a normal operating system (i.e. perhaps not Plan 9, I am not sure) the debug symbols are separate from the executable text so that the OS will never read the debug symbol area while it is loading the program. This means that there should be no performance difference. If you say so, then I guess I am imagining things ;) I have never given the issue much thought until now, I suppose I need to do a bit more research on the issue. -- The angel of history[...]is turned toward the past. (Walter Benjamin)
Re: default -g ??!?
MK halfcountp...@intergate.com writes: Ah, it's because of GNU make: No it's not. By default, the Make rules should compile and link with -g, so that executable programs have debugging symbols. Users who don't mind being helpless can strip the executables later if they wish. Nice, flexible software it ain't. That isn't anything GNU make does, it's a _recommendation_ for Makefile writers. Automake, accordingly follows that recommendation, since it's a higher-level too than make, and tries to provide sensible defaults (whereas GNU make has no default compiler options). -Miles -- Christian, n. One who follows the teachings of Christ so long as they are not inconsistent with a life of sin.
Re: default -g ??!?
MK halfcountp...@intergate.com writes: If you say so, then I guess I am imagining things ;) I have never given the issue much thought until now, I suppose I need to do a bit more research on the issue. Indeed, it's often a good idea to do the research _before_ posting flames and rants... -miles -- ((lambda (x) (list x x)) (lambda (x) (list x x)))
