[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Python version requirements vs qemu-upstream



On Wed, 2014-01-15 at 09:27 +0000, Jan Beulich wrote:
> According to our own documentation, even Python 2.3 is supported
> for building,

It might be time to consider reving that. Current state of some distros:

Debian Squeeze (oldstable): 2.6
Debian Wheezy (stable): 2.7
RHEL 5.9: 2.4
RHEL 4.8: 2.3
SLES 11SP3: 2.6
SLES 10SP4: 2.4

So by bumping to a minimum version of 2.4 we would be dropping support
for RHEL4 dom0 userspace -- Personally I think that would be acceptable,
it's now RHEL's old-old-stable (unless RHEL7 happened while I wasn't
paying attention, which is possible).

Bumping further than 2.4 would mean dropping RHEL5 and SLES10, neither
of which seem desirable to drop unnecessarily. (If there were known
issues with 2.4 then I would be inclined to re-evaluate that though)

>  yet the qemu-upstream version update results in that
> part of the build no longer working with Python 2.4 due to a number
> of conditional assignments like this
> 
>     full_name = name if not fn_prefix else "%s_%s" % (name, fn_prefix)
> 
> in scripts/qapi-visit.py.

This is consistent with their configure script which checks for:
        # Note that if the Python conditional here evaluates True we will exit
        # with status 1 which is a shell 'false' value.
        if ! $python -c 'import sys; sys.exit(sys.version_info < (2,4) or 
sys.version_info >= (3,))'; then
          error_exit "Cannot use '$python', Python 2.4 or later is required." \
              "Note that Python 3 or later is not yet supported." \
              "Use --python=/path/to/python to specify a supported Python."
        fi

Did you hit that too?

> Converting these instances to proper conditionals fixes the issue
> for me.
> 
> I further found that with some gcc versions trace/control-internal.h
> causes a huge amount of warnings to be generated. While this isn't
> keeping the build from succeeding, it's still rather annoying.

Ancient versions of gcc I presume?

> The combined full fix for both issues is below. But I'm uncertain
> whether sending these to qemu-devel would make any sense, as
> I have no idea whether such old build environments are being
> cared about there.

I don't know about that, but at least the Python ones do not look like
improvements in their own right.

> 
> Jan
> 
> --- a/scripts/qapi-visit.py
> +++ b/scripts/qapi-visit.py
> @@ -20,7 +20,10 @@ import errno
>  def generate_visit_struct_fields(name, field_prefix, fn_prefix, members):
>      substructs = []
>      ret = ''
> -    full_name = name if not fn_prefix else "%s_%s" % (name, fn_prefix)
> +    if not fn_prefix:
> +        full_name = name
> +    else:
> +        full_name = "%s_%s" % (name, fn_prefix)
>  
>      for argname, argentry, optional, structured in parse_args(members):
>          if structured:
> @@ -84,7 +87,10 @@ if (!error_is_set(errp)) {
>  ''')
>      push_indent()
>  
> -    full_name = name if not field_prefix else "%s_%s" % (field_prefix, name)
> +    if not field_prefix:
> +        full_name = name
> +    else:
> +        full_name = "%s_%s" % (field_prefix, name)
>  
>      if len(field_prefix):
>          ret += mcgen('''
> @@ -226,6 +232,10 @@ def generate_visit_union(expr):
>  
>      base = expr.get('base')
>      discriminator = expr.get('discriminator')
> +    if not discriminator:
> +        type="type"
> +    else:
> +        type=discriminator
>  
>      if discriminator == {}:
>          assert not base
> @@ -270,7 +280,7 @@ void visit_type_%(name)s(Visitor *m, %(n
>          if (!err) {
>              switch ((*obj)->kind) {
>  ''',
> -                 name=name, type="type" if not discriminator else 
> discriminator)
> +                 name=name, type=type)
>  
>      for key in members:
>          if not discriminator:
> --- a/trace/control-internal.h
> +++ b/trace/control-internal.h
> @@ -16,15 +16,15 @@
>  extern TraceEvent trace_events[];
>  
> 
> -static inline TraceEvent *trace_event_id(TraceEventID id)
> +static inline TraceEventID trace_event_count(void)
>  {
> -    assert(id < trace_event_count());
> -    return &trace_events[id];
> +    return TRACE_EVENT_COUNT;
>  }
>  
> -static inline TraceEventID trace_event_count(void)
> +static inline TraceEvent *trace_event_id(TraceEventID id)
>  {
> -    return TRACE_EVENT_COUNT;
> +    assert(id < trace_event_count());
> +    return &trace_events[id];
>  }
>  
>  static inline bool trace_event_is_pattern(const char *str)
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.