Re: [Xen-devel] [PATCH 28/28] Separate runtime debug output from debug symbols

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 26.09.14 at 10:17, <olaf@xxxxxxxxx> wrote:
> 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?

Sounds reasonable.

> 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.

We could certain borrow some of Linux'es build machinery for this,
but iirc even they don't go as far as rebuilding when tool chain
component versions change (and unless there are bugs in the tool
chain I also don't think that's necessary).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel