Bug 89328

Summary: python required to build Mesa release tarballs
Product: Mesa Reporter: Jonathan Gray <jsg>
Component: Mesa coreAssignee: mesa-dev
Status: RESOLVED FIXED QA Contact: mesa-dev
Severity: normal    
Priority: medium CC: emil.l.velikov, jason, siglesias
Version: 10.5   
Hardware: All   
OS: OpenBSD   
Whiteboard:
i915 platform: i915 features:
Attachments: remove mako check when python is not installed

Description Jonathan Gray 2015-02-26 01:18:43 UTC 
Mesa releases will not build without python.  According to Emil Velikov this is not the intended behaviour.

With the Mesa 10.5.0 rc2 tarball:

A build log with python installed --disable-silent-rules contains

python  ./mapi_abi.py --mode lib --printer shared-glapi glapi/gen/gl_and_es_API.xml > shared-glapi/glapi_mapi_tmp.h
python  ./main/get_hash_generator.py            \
python  ./main/format_info.py        \
python  ./gen_xmlpool.py ./t_options.h . ca de es nl fr sv > options.h

With python not installed

checking build system type... x86_64-unknown-openbsd5.7
checking host system type... x86_64-unknown-openbsd5.7
checking target system type... x86_64-unknown-openbsd5.7
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... bin/install-sh -c -d
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether UID '1000' is supported by ustar format... yes
checking whether GID '1000' is supported by ustar format... yes
checking how to create a ustar tar archive... plaintar
checking whether make supports nested variables... (cached) yes
checking for style of include used by make... GNU
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking dependency style of gcc... gcc3
checking for ar... ar
checking the archiver (ar) interface... ar
checking how to run the C preprocessor... gcc -E
checking for gcc... (cached) gcc
checking whether we are using the GNU C compiler... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for gcc option to accept ISO C89... (cached) none needed
checking whether gcc understands -c and -o together... (cached) yes
checking dependency style of gcc... (cached) gcc3
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking dependency style of g++... gcc3
checking dependency style of gcc... gcc3
checking for GNU make... 
"Not found"
checking for python2... no
checking for python... no
checking for a sed that does not truncate output... /usr/bin/sed
checking for special C compiler options needed for large files... no
checking for _FILE_OFFSET_BITS value needed for large files... no
checking how to print strings... print -r
checking for a sed that does not truncate output... (cached) /usr/bin/sed
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for fgrep... /usr/bin/grep -F
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 196608
checking how to convert x86_64-unknown-openbsd5.7 file names to x86_64-unknown-openbsd5.7 format... func_convert_file_noop
checking how to convert x86_64-unknown-openbsd5.7 file names to toolchain format... func_convert_file_noop
checking for /usr/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... match_pattern /lib[^/]+(\.so\.[0-9]+\.[0-9]+|\.so|_pic\.a)$
checking for dlltool... no
checking how to associate runtime and link libraries... print -r --
checking for archiver @FILE support... no
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for sysroot... no
checking for a working dd... /bin/dd
checking how to truncate binary pipes... /bin/dd bs=4096 count=1
checking for mt... mt
checking if mt is a manifest tool... no
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC -DPIC
checking if gcc PIC flag -fPIC -DPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes
checking whether -lc should be explicitly linked in... yes
checking dynamic linker characteristics... openbsd5.7 ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
checking how to run the C++ preprocessor... g++ -E
checking for ld used by g++... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes
checking for g++ option to produce PIC... -fPIC -DPIC
checking if g++ PIC flag -fPIC -DPIC works... yes
checking if g++ static flag -static works... yes
checking if g++ supports -c -o file.o... yes
checking if g++ supports -c -o file.o... (cached) yes
checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes
checking dynamic linker characteristics... openbsd5.7 ld.so
checking how to hardcode library paths into programs... immediate
checking for bison... no
checking for byacc... no
checking if bison is the parser generator... no
checking for flex... flex
checking lex output file root... lex.yy
checking lex library... -lfl
checking whether yytext is a pointer... yes
checking if flex is the lexer generator... yes
checking for indent... indent
indent: Command line: unknown parameter "--version"
checking if module mako in python is installed... ./configure[18482]: -: not found
configure: error: mako 0.3.4 or later is required.
Comment 1 Samuel Iglesias Gonsálvez 2015-02-26 08:00:37 UTC 
Since commit 2b37bea010a9c, the format-handling code is auto-generated via python scripts and mako templates, so python is required. Also, Python is listed in the prerequisites for building Mesa in the docs:

   http://www.mesa3d.org/install.html

Maybe we need to modify our configure.ac to mark Python as hard dependency.
Comment 2 Emil Velikov 2015-02-26 12:58:19 UTC 
(In reply to Samuel Iglesias from comment #1)
> Since commit 2b37bea010a9c, the format-handling code is auto-generated via
> python scripts and mako templates, so python is required.
> Also, Python is
> listed in the prerequisites for building Mesa in the docs:
> 
>    http://www.mesa3d.org/install.html
> 
> Maybe we need to modify our configure.ac to mark Python as hard dependency.
That is correct but for building from git alone.

The distribution tarballs (should) provide all the auto-generated files, similar to any other autotools project. As such one should not need any of python/mako/lex/etc but a plain compiler toolchain.

Imho we should fix these in a way that, when the files are generated, all the non-compiler requirements are non-fatal.

Although I cannot find a way to do that of the top of my head.

At the end it would be nice to update the doc :-)
Comment 3 Samuel Iglesias Gonsálvez 2015-02-27 08:20:43 UTC 
Created attachment 113857 [details] [review]
remove mako check when python is not installed

> The distribution tarballs (should) provide all the auto-generated files, 
> similar to any other autotools project. As such one should not need any of 
> python/mako/lex/etc but a plain compiler toolchain.
> 
> Imho we should fix these in a way that, when the files are generated, all the 
> non-compiler requirements are non-fatal.
> 

I wrote a patch (attached) that removes the python mako module check when python is not installed in the system. If it needs to do something with python, it is going to fail anyway.

I tested this patch in a virtual machine without python installed to check if I can compile mesa from a tarball created by 'make dist' command. At least now, mako doesn't block the configuration step. The build fails at a later time due to some python files but unrelated to autogenerated format_pack.c and format_unpack.c files because the latter ones were already generated by make dist.

If you think this patch is interesting to have in master, just say so and I will send this patch to the mailing list.

> Although I cannot find a way to do that of the top of my head.
Comment 4 Emil Velikov 2015-02-27 14:44:42 UTC 
(In reply to Samuel Iglesias from comment #3)
> I wrote a patch (attached) that removes the python mako module check when
> python is not installed in the system. If it needs to do something with
> python, it is going to fail anyway.
> 
True.

> If you think this patch is interesting to have in master, just say so and I
> will send this patch to the mailing list.
> 
Imho the patch looks good. Alternative solution is to have the macro set a variable that we check in configure (like below), but let see what others think on the ML.

PYTHON_MAKO_REQUIRED=0.3.4
AX_CHECK_PYTHON_MAKO_MODULE($PYTHON_MAKO_REQUIRED)
if test -n "$PYTHON2" -a $foo_mako_found = no; then
    AC_MSG_ERROR([Python mako module v$PYTHON_MAKO_MODULE not found])
fi


Thank you Samuel!
Comment 5 Emil Velikov 2015-03-28 22:07:00 UTC 
Hi Jonathan,

Can you give mesa 10.5.2 a try and reopen if this is still an issue. It's not perfect solution atm, as configure will error out if you have python while mako is not found. There are some patches that should resolve this but they haven't been reviewed yet.

Thanks
Emil

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.