Bug 107565 - TypeError: __init__() got an unexpected keyword argument 'future_imports'
Summary: TypeError: __init__() got an unexpected keyword argument 'future_imports'
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Mesa core (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Dylan Baker
QA Contact: mesa-dev
URL:
Whiteboard:
Keywords: bisected, regression
Depends on:
Blocks:
 
Reported: 2018-08-14 07:01 UTC by Vinson Lee
Modified: 2018-12-07 15:54 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Vinson Lee 2018-08-14 07:01:36 UTC
Build error with Python 2.6.

  GEN    main/format_unpack.c
Traceback (most recent call last):
  File "./main/format_unpack.py", line 893, in <module>
    template = Template(string, future_imports=['division']);
TypeError: __init__() got an unexpected keyword argument 'future_imports'

commit 9b6746b7c0bef64be419c8cf2ecd916980e2718a
Author: Mathieu Bridon <bochecha@daitauha.fr>
Date:   Wed Jul 25 11:53:54 2018 +0200

    python: Use explicit integer divisions
    
    In Python 2, divisions of integers return an integer:
    
        >>> 32 / 4
        8
    
    In Python 3 though, they return floats:
    
        >>> 32 / 4
        8.0
    
    However, Python 3 has an explicit integer division operator:
    
        >>> 32 // 4
        8
    
    That operator exists on Python >= 2.2, so let's use it everywhere to
    make the scripts compatible with both Python 2 and 3.
    
    In addition, using __future__.division tells Python 2 to behave the same
    way as Python 3, which helps ensure the scripts produce the same output
    in both versions of Python.
    
    Signed-off-by: Mathieu Bridon <bochecha@daitauha.fr>
    Reviewed-by: Eric Engestrom <eric.engestrom@intel.com> (v2)
    Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
Comment 1 Dylan Baker 2018-08-14 16:08:03 UTC
Scons doesn't check that mako is at least 0.8.0 like autotools does (which was released in 2013, btw). The real bug here is that scons doesn't do proper checks like it should.
Comment 2 Emil Velikov 2018-12-07 15:54:02 UTC
Should be fixed with the following commit. Feel free to reopen otherwise.

commit c782168751ec6373c28ebb4b4c39a8f3ae06a075
Author: Dylan Baker <dylan@pnwbakers.com>
Date:   Tue Aug 14 10:32:12 2018 -0700

    scons: Check for mako 0.8.0


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.