On Fri, Sep 10, 1999 at 01:25:25AM +0200, Marcus Brinkmann wrote:
> Mmh. I see your point. What about having "debug" and "strip"? This would
> allow for:
>
> DEB_DEBUG_OPTION=debug nostrip # Build debug packages.
> DEB_DEBUG_OPTION=debug # Build debug files, but strip them in package.
>
>
On Thu, Sep 09, 1999 at 05:06:32PM -0400, Raul Miller wrote:
>
> Personally, I'd recommend defining DEB_DEBUG_OPTION=debug-strip which
> would build with debugging symbols, but strip for package generation
> then strip.
Mmh. I see your point. What about having "debug" and "strip"? This would
allo
On Thu, Sep 09, 1999 at 05:06:32PM -0400, Raul Miller wrote:
> This seems overall like a decent plan, but there are a few cases I'd be
> concerned about:
>
> (a) Developer builds package, something gets upgraded on developer's
> (libc, gcc, whatever), an executable dumps core on client machine --
On Thu, Sep 09, 1999 at 08:42:18PM +0200, Marcus Brinkmann wrote:
> Yes, and I acknowledge your goal. But I am concerned that people will just
> drop the -g without replacement, and the rest choose the suggested way or
> another. What I would like to see is to have some unified way to pass build
>
On Thu, Sep 09, 1999 at 08:42:18PM +0200, Marcus Brinkmann wrote:
> > Sorry to see you take this to that extreme. I'm voicing my opinion. If I
> > feel that
> > there is speific agreement that it _should_ be forced instead of suggested,
> > I'll be
> > more than happy to comply and change the pro
On Thu, Sep 09, 1999 at 11:48:48AM -0400, Ben Collins wrote:
> On Thu, Sep 09, 1999 at 08:14:36PM +0200, Marcus Brinkmann wrote:
> > On Thu, Sep 09, 1999 at 11:20:48AM -0400, Ben Collins wrote:
> > > "You have to implement debugging this way if you are going to
> > > support it". Two reasons:
> > >
On Thu, Sep 09, 1999 at 08:14:36PM +0200, Marcus Brinkmann wrote:
> On Thu, Sep 09, 1999 at 11:20:48AM -0400, Ben Collins wrote:
> > "You have to implement debugging this way if you are going to
> > support it". Two reasons:
> >
> > 1) Right now policy does not require -g, but only suggests an
> >
On Thu, Sep 09, 1999 at 11:20:48AM -0400, Ben Collins wrote:
> "You have to implement debugging this way if you are going to
> support it". Two reasons:
>
> 1) Right now policy does not require -g, but only suggests an
>example, yet everyone is compilg this way. I don't think our
>develope
I just wanted to comment that I don't think the wording should be
"You have to implement debugging this way if you are going to
support it". Two reasons:
1) Right now policy does not require -g, but only suggests an
example, yet everyone is compilg this way. I don't think our
developers have
On Thu, Sep 09, 1999 at 11:32:17PM +1000, Anthony Towns wrote:
> On Thu, Sep 09, 1999 at 02:45:19PM +0200, Marcus Brinkmann wrote:
> > On Wed, Sep 08, 1999 at 09:24:06PM -0400, Raul Miller wrote:
> > > (2) You want some way to prevent the executables from being stripped
> > > before they're install
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> Minor correction: Only if it is supported. I can think of some
> upstream software which does not support this very well or at
> all. However, if it can be supported, it should be, and if it is
> supported, it must be supported through a well defined
On Thu, Sep 09, 1999 at 02:45:19PM +0200, Marcus Brinkmann wrote:
> On Wed, Sep 08, 1999 at 09:24:06PM -0400, Raul Miller wrote:
> > (2) You want some way to prevent the executables from being stripped
> > before they're installed on the target system. [Depreciating the current
> > unconditional s
Hi,
On Wed, Sep 08, 1999 at 09:24:06PM -0400, Raul Miller wrote:
> On Thu, Sep 09, 1999 at 02:19:36AM +0200, Marcus Brinkmann wrote:
> > Raul, how hard do you want to make it for users to build with debugging
> > info? Activating a gcc wrapper, changing install and strip. This is
> > completely un
On Thu, Sep 09, 1999 at 02:19:36AM +0200, Marcus Brinkmann wrote:
> Raul, how hard do you want to make it for users to build with debugging
> info? Activating a gcc wrapper, changing install and strip. This is
> completely unreasonable.
I think I could build you a package which does this for you i
On Wed, Sep 08, 1999 at 08:29:09PM -0400, Raul Miller wrote:
> >
> > This means, packages may choose other ways to specify "build with
> > debug symbols", and I can't be sure any longer what to do to get debug
> > symbols (in cases where they are supported).
>
> I don't see a meaningful distinctio
On Wed, Sep 08, 1999 at 05:30:09PM +0200, Marcus Brinkmann wrote:
> > You can always build with DEB_DEBUG_OPTIONS=debug and expect that the
> > executables created will have debug symbols. This is already true even
> > without this policy being implemented.
>
> This is true now, but with the prop
On Wed, Sep 08, 1999 at 10:12:28AM -0400, Ben Collins wrote:
> > (1) impact on my packages,
>
> The proposal will not force you to change anything.
Why are you saying this?
Earlier instances of the proposal were advertised as requiring a change.
Future instances of the proposal may also, as migh
On Wed, Sep 08, 1999 at 08:32:16AM -0400, Ben Collins wrote:
> I have benchmarked this, and most of the larger packages (those that
> build several megs or more of object files, which with -g on, was quite a
> lot) saw a roughly 15% increase in speed during compiles. Now this is on a
> fast Ultra
On Wed, Sep 08, 1999 at 08:34:48AM -0400, Ben Collins wrote:
> And it seems this would be correct. For the user to have a debuggable
> package they must have downloaded the source and built it with
> DEB_BUILD_OPTIONS=debug. So it is safe to say that they _will_ have the
> source around.
Or the
On Wed, Sep 08, 1999 at 10:36:52AM -0400, Raul Miller wrote:
> On Wed, Sep 08, 1999 at 08:32:16AM -0400, Ben Collins wrote:
> > Raul, you seem to have no real interest in this proposal.
>
> I do have an interest -- I'm not concerned about the speed benefits,
> but I very much do have an interest.
Raul Miller wrote:
>
> On Wed, Sep 08, 1999 at 02:52:59PM +0200, Marcus Brinkmann wrote:
> > This is why I think a suggestion is too weak. You can equally well remove
> > the suggestion, because I can't rely on it and have to check always if a
> > package follows the policy suggestion or does it d
On Wed, Sep 08, 1999 at 08:32:16AM -0400, Ben Collins wrote:
> Raul, you seem to have no real interest in this proposal.
I do have an interest -- I'm not concerned about the speed benefits,
but I very much do have an interest.
In particular, I care about:
(1) impact on my packages,
(2) impact
On Wed, Sep 08, 1999 at 09:58:57AM -0400, Raul Miller wrote:
> > And, for debugging, you probably want the source environment around...
>
> This is fairly important: debugging is a manual process.
And it seems this would be correct. For the user to have a debuggable
package they must have downloa
On Wed, Sep 08, 1999 at 09:39:23AM -0400, Raul Miller wrote:
> ...Ben's proposal is purely an optimization. [I'm not sure if anyone
> has benchmarked it -- and while I hope someone cares about benchmarking
> optimizations, I don't care enough myself. My packages compile in a
> few seconds on the
On Wed, Sep 08, 1999 at 09:39:23AM -0400, Raul Miller wrote:
> You can always build with DEB_DEBUG_OPTIONS=debug and expect that the
> executables created will have debug symbols. This is already true even
> without this policy being implemented.
Correction: this is true for some packages now, a
On Wed, Sep 08, 1999 at 02:52:59PM +0200, Marcus Brinkmann wrote:
> This is why I think a suggestion is too weak. You can equally well remove
> the suggestion, because I can't rely on it and have to check always if a
> package follows the policy suggestion or does it differently.
No.
You can alwa
On Tue, Sep 07, 1999 at 03:14:56PM -0700, Chris Waters wrote:
> Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> > On Tue, Sep 07, 1999 at 01:11:33PM -0700, Chris Waters wrote:
> > > If the binaries can be debugged in the build directories, then there's
> > > little reason not to strip them.
>
> > T
On Tue, Sep 07, 1999 at 06:10:06PM -0400, Ben Collins wrote:
> What I mean by that is, if we just say that policy suggests building without
> -g, then some package maintainers _will_ implement a way of getting debuggable
> binaries (or objects as your may be). We want this implementation to stay
>
On Wed, Sep 08, 1999 at 07:07:15AM -0400, Raul Miller wrote:
> On Tue, Sep 07, 1999 at 09:37:19PM -0400, Ben Collins wrote:
> > Umm, how do you see your hack as a speed gain when it requires every
> > invocation of gcc to also invoke perl?!
>
> I guess that means you didn't read the rest of the me
On Wed, Sep 08, 1999 at 01:58:54PM +1000, Anthony Towns wrote:
> Huh? As in "Build-Depends: gcc (= 2.7.2)" ? How's this different to
> Bug#41232? Or, rather, how is Bug#41232 lacking?
Bug#41232 is good, though [to take the example from the most recent
message], I still don't see that specifying al
On Tue, Sep 07, 1999 at 09:37:19PM -0400, Ben Collins wrote:
> Umm, how do you see your hack as a speed gain when it requires every
> invocation of gcc to also invoke perl?!
I guess that means you didn't read the rest of the message.
It's trivial to rewrite in C, and I offered to do so.
> So you
On Tue, Sep 07, 1999 at 09:47:32PM -0400, Raul Miller wrote:
> In the long run, we need a decent source dependency system, which
> integrates well with the build environment. [I'm imagining something
> along the lines of bsd's .include designed for
> debian/rules, and a source dependency system t
On Tue, Sep 07, 1999 at 09:47:32PM -0400, Raul Miller wrote:
> On Tue, Sep 07, 1999 at 06:12:07PM -0400, Ben Collins wrote:
> > Umm, what about libraries that purposely compile -dbg packages? This
> > is a silly idea, it's not a good idea for the autobuilders to muck
> > around with the way the pac
On Tue, Sep 07, 1999 at 06:12:07PM -0400, Ben Collins wrote:
> Umm, what about libraries that purposely compile -dbg packages? This
> is a silly idea, it's not a good idea for the autobuilders to muck
> around with the way the package is meant to be built.
Good point.
Of course, this is solvable
On Tue, Sep 07, 1999 at 06:55:43PM -0400, Raul Miller wrote:
> On Tue, Sep 07, 1999 at 05:38:03PM +0200, Roman Hodek wrote:
> > You forgot the case of recompilations: If default is with -g + strip
> > (as policy currently recommends), a lot of time is wasted on the
> > auto-builder machines.
>
> I
On Tue, Sep 07, 1999 at 03:14:56PM -0700, Chris Waters wrote:
>
> If we (the project, not individual developers) are not going to
> distribute packages with debug info included, I see no reason for
> policy to concern itself with the requirement (or even recommendation)
> to make it possible to bu
On Tue, Sep 07, 1999 at 05:38:03PM +0200, Roman Hodek wrote:
> You forgot the case of recompilations: If default is with -g + strip
> (as policy currently recommends), a lot of time is wasted on the
> auto-builder machines.
I think something like the following would work for auto-builder machines:
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> On Tue, Sep 07, 1999 at 01:11:33PM -0700, Chris Waters wrote:
> > If the binaries can be debugged in the build directories, then there's
> > little reason not to strip them.
> That's an assumption that may or not may be met. We should not base
> our
On Tue, Sep 07, 1999 at 01:11:33PM -0700, Chris Waters wrote:
>
> I think that you have far too little trust in the common sense of
> developers. I think that if policy merely suggests it, most
> developers will follow the suggestion if it's at all reasonable to do
> so.
I think we should not be
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> On Tue, Sep 07, 1999 at 08:24:06AM -0400, Ben Collins wrote:
> > If you want users to be able
> > to rebuild your package with debugging information easily, the suggested
> > way is to use the ``DEB_BUILD_OPTIONS'' environment variable.
> This is wa
On Tue, Sep 07, 1999 at 08:24:06AM -0400, Ben Collins wrote:
>
> Ok, this is my last attempt for a crowd pleaser.
I hope not.
> This new an improved
> proposal should satisfy any and all complaints (as few as they were). This
> new proposal has several added features.
Unfortunately, I dislike t
> Let's assume that you care to keep executables with debugging
> symbols around. In that case, the old recommendation would
> have you build the package once. The new recommendation
> would have you compile twice. Time saved?
>
> Let's assume that you don't care to keep executables with
> deb
On Tue, Sep 07, 1999 at 10:59:08AM -0400, Raul Miller wrote:
> On Tue, Sep 07, 1999 at 08:24:06AM -0400, Ben Collins wrote:
> > Ok, this is my last attempt for a crowd pleaser. This new an improved
> > proposal should satisfy any and all complaints (as few as they were).
> > This new proposal has s
On Tue, Sep 07, 1999 at 08:24:06AM -0400, Ben Collins wrote:
> Ok, this is my last attempt for a crowd pleaser. This new an improved
> proposal should satisfy any and all complaints (as few as they were).
> This new proposal has several added features.
I still think this makes the whole recommenda
retitle 43787 [AMENDED 07/09/1999] policy on -g, a proposal
thanks
Ok, this is my last attempt for a crowd pleaser. This new an improved
proposal should satisfy any and all complaints (as few as they were). This
new proposal has several added features.
1) Raul was correct in that policy does nto
45 matches
Mail list logo
