From mboxrd@z Thu Jan 1 00:00:00 1970 From: Olaf Hering Subject: Re: [PATCH 28/28] Separate runtime debug output from debug symbols Date: Fri, 26 Sep 2014 10:17:35 +0200 Message-ID: <20140926081735.GA26733@aepfle.de> References: <1411658423-18877-1-git-send-email-olaf@aepfle.de> <1411658423-18877-29-git-send-email-olaf@aepfle.de> <5424587E02000078000391F1@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <5424587E02000078000391F1@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: Wei Liu , Ian Campbell , Stefano Stabellini , Tim Deegan , Ian Jackson , xen-devel@lists.xen.org, Samuel Thibault , Keir Fraser , David Scott List-Id: xen-devel@lists.xenproject.org On Thu, Sep 25, Jan Beulich wrote: > I'm having mixed feelings with this: On one hand it's nice to control > this on the command line. Otoh, since you don't force a full rebuild > when the setting changes between (incremental) builds, I'm not > certain a proper binary will result (or the build even succeed). Yes, > that's already a problem for the hypervisor build without this patch > (and I think such settings should only be passed through .config, > which should never be changed after an initial build), but extending > this doesn't necessarily seem like the right route. After spending some more time on this it looks my change regarding tools and stubdom can be done in a different way. Initially I was thinking that "var ?= val" will override "var := val", but its exactly the opposite. So for xen builds the patch will not change much except that it separates runtime debug from debug symbols. For the tools+stubdom side I suggest to have to knobs: --enable-debug for runtime debug like it is done today, and a new --enable-debug-info or --enable-debug_symbols which controls just the "-g" flag. Any objections to that approach? Regarding the rebuild if the compile environment changes: I'm in favour of that. Just recently I upgraded from SLE11 to SLE12 and I had to cleanup first before running make again. Maybe there is a way that everything depends on some header (or knob) which contains CFLAGS, LDFLAGS, the toolchain path and other build related things. If some of that changes, force a rebuild. Olaf