MK 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) (li
MK 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.
On Sat, 20 Nov 2010 14:21:27 -0600 (CST)
Bob Friesenhahn 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 m
* 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
On Sat, 20 Nov 2010 14:17:14 -0600 (CST)
Bob Friesenhahn 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 w
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 tim
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 lo
On Sat, 20 Nov 2010 17:31:32 +
Roger Leigh 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 th
On Sat, 20 Nov 2010 12:13:38 -0500
Paul Smith 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
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
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
On Sat, 2010-11-20 at 10:36 -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, flexi
On Sat, 20 Nov 2010 16:51:48 +0100
Ralf Wildenhues wrote:
> > > 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 configur
On Sat, 20 Nov 2010 10:36:34 -0500
MK 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. Anyw
* 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
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
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. Th
On Sat, 20 Nov 2010 15:31:01 +0100
Ralf Wildenhues wrote:
> 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
That does not make sense for a few reas
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
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
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 m
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 th
* 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 to
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
* 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 o
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
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 toplev
* 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 $(
28 matches
Mail list logo
