Re: [libvirt] [python PATCH] build: make it easier to backport event ids

On 01/15/2015 03:51 AM, Jiri Denemark wrote: > On Thu, Jan 15, 2015 at 10:42:39 +0000, Daniel Berrange wrote: >> On Wed, Jan 14, 2015 at 08:08:16PM -0700, Eric Blake wrote: >>> In some cases, it is very easy for downstream distros to backport >>> enum values without requiring a .so bump. Keying the conditional >>> code off of the upstream version where the enum value was added >>> is not ideal, because downstream then has to patch that the feature >>> is available in their build that still reports an earlier version >>> number. For example, if RHEL 7 backports events from 1.2.11 into >>> a build based on 1.2.8, building the python bindings would warn: >>> >>> + if name.startswith('VIR_DOMAIN_EVENT_ID_') or name.startswith('VIR_NETWORK_EVENT_ID_'): >>> + event_ids.append(name) >> >> If you use brackets you can break the line without confusing >> python eg >> >> if (name.startswith('VIR_DOMAIN_EVENT_ID_') or >> name.startswith('VIR_NETWORK_EVENT_ID_')): Thanks. >>> + # Write define wrappers around event id enums >>> + include.write("\n") >>> + for event_id in event_ids: >>> + include.write("#define %s %s\n" % (event_id, event_id)) >> >> I'm not seeing the point of adding this define ? > ... >>> -#if LIBVIR_CHECK_VERSION(0, 10, 0) >>> +#ifdef VIR_DOMAIN_EVENT_ID_BALLOON_CHANGE > > Without that define, you can't check for the events using ifdef, > C preprocessor doesn't see enum items. Correct. Creating self-referential macros is the canonical way to convert enums into something that can be probed at preprocessor time for using conditional compilation. Since we have one macro for every enum that we read from the xml of the libvirt we are targetting, we can make the bindings support exactly the set of enum values that were backported into the particular libvirt, without having to worry about backporting crossing version number checks.

So does this count as an ACK with the long line fixed?