* 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)?
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
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
* 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
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
* 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
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
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
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
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.
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
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
* 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
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
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,
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
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
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).
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
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
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
* 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
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
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,
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...
* 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
#
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
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
* 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)?
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
* 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
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.
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
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.
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
* 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
* 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
* 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
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
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
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
* 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
-
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
43 matches
Mail list logo
