Disabling python support does not prevent entry into python directories during build

[brook]

The configure option --without-python is presumably supposed to disable all python support. However, the Makefiles are set to unconditionally enter the gui/wxpython and lib/python subdirectories. As a result, this option results in a failed build.

The solution is to conditionally include those directories in the list of subdirectories for make. Two patches against the 6.4.2 release that fix this are attached. This has been compile-checked on a NetBSD system both with and without the --without-python option.

Presumably this should be pulled up to the more recent versions as well.

[brook]

Patch to gui/Makefile

[brook]

Patch to lib/Makefile

[neteler]

Thanks, applied to G6.4 and G6.5 in r53326 and r53327.

For GRASS 7 which highly depends on Python this changes does not make sense.

[glynn]

Replying to brook:

The configure option --without-python is presumably supposed to disable all python support.

Incorrect. It's supposed to disable building C/C++ components which link against the Python library (are there any of these left in 6.x?).

However, the Makefiles are set to unconditionally enter the gui/wxpython and lib/python subdirectories.

This is correct.

As a result, this option results in a failed build.

Error message? Other symptoms?

The solution is to conditionally include those directories in the list of subdirectories for make. Two patches against the 6.4.2 release that fix this are attached. This has been compile-checked on a NetBSD system both with and without the --without-python option. Presumably this should be pulled up to the more recent versions as well.

It shouldn't go into any version; r53326 and r53327 are in error. If the build fails due to a missing Python interpreter, the Makefiles should be fixed so that such errors are reported and ignored, rather than aborting the build.

A couple of things which stand out are the menustrings.py rule in gui/wxpython/Makefile, as well as the rule which runs createinit.py. The former is decidedly non-critical (it just means that "make -C locale pot" won't get the strings from the XML files for the menus). The latter should ideally be fixed to not require Python; the wxGUI should should only require Python on the target system, not on the build system.

[brook]

I take it from the above comment that python is a required prerequisite for grass, even for 6.4.2. If that is the case, it should be listed among the prerequisites; it is not. If that is not the case, it should be possible to build grass correctly without python, something that I expected the --without-python to accomplish. If that is not the correct way to build grass without python, then perhaps that should instead be documented.

It is unclear to me what the correct state is:

- Is python a required prerequisite for grass 6.4.2? (I hope it is documented as such for GRASS 7 as it sounds like it is a requirement.)

- What is the correct way, if any, to build grass 6.4.2 without python?

[glynn]

Replying to brook:

I take it from the above comment that python is a required prerequisite for grass, even for 6.4.2.

No, it's not required. At least, it shouldn't be.

If that is not the case, it should be possible to build grass correctly without python,

Correct.

something that I expected the --without-python to accomplish.

It should be possible with or without that switch. In fact, the switch shouldn't even exist; it serves no purpose, as there are no longer any modules which need to be compiled against the Python library and headers.

- Is python a required prerequisite for grass 6.4.2?

No.

(I hope it is documented as such for GRASS 7 as it sounds like it is a requirement.)

It is a requirement for 7.0, and it's documented.

- What is the correct way, if any, to build grass 6.4.2 without python?

The presence or absence of Python should not affect the build. If it does, that's a bug in the build system. Modules which require Python (e.g. wxGUI) should be installed regardless of the presence or absence of Python on the build system. Obviously, such modules won't work if you don't have Python on the target system.

However: there are a couple of inevitable shortcomings if the build system lacks Python:

• Python scripts (I think this is just v.krige) won't have manual pages.

• The source message catalogue won't contain the strings used in the wxGUI menus.

• Possibly other minor details. The issue is similar to cross-compiling: portions of the build system which rely upon the ability to execute the programs being built won't work if those programs are written in Python and you don't have Python on the build system. The main thing is that such issues should not prevent other components from being built.

One issue I have noticed is gui/wxpython/create__init__.py which creates the __init__.py files for parts of the wxGUI. In 6.x, this should be a shell script, as Python isn't a requirement for the build system. Failing that, it should be included as part of the installation so that the build process can be completed on the target system.

[hamish]

Hi,

fwiw I have an old system which doesn't have a new enough wxWidgets (v2.6) to run the grass wx gui, so since development on it began I've built there with --with-python=/usr/bin/python2.4-config and --without-wxwidgets without any build errors.

It has been some months since I've rebuilt grass there, but as of about 6.4.2 it still worked fine after using g.gui to set the default to tcl/tk.

Hamish

[hamish]

[trac is logging me out every 5 minutes.. arrgh]

I just tried rebuilding on the old machine --with-python and --without-wxwidgets in comment:5, it was ok.

Building with 'make -j 5' I did get an error logged in the gui/wxpython/ dir, but cd'ing to it and running make again was successful, so I suspect that some Makefile order-of-build dependency issue still exists, but overall it's happy.

Is the goal to build on a system without any python on it, to build on a system without wxWidgets on it, or to just not build the wxGUI?

If it's just to avoid building with the wxGUI it's not really a problem, since most of it is not really built, just copied in place and then left unused.

As a result, this option results in a failed build.

what was the error?

Hamish

[hamish]

I just tried 6.4.3svn again --without-python and --without-wxwidgets.

The experience was the same. It still tried to make the wxwidgets gui, and failed with this error:

...
python -m py_compile /usr/local/src/grass/svn/releasebranch_6_4/dist.i686-pc-linux-gnu/etc/wxpython/wxplot/profile.py
python -m py_compile /usr/local/src/grass/svn/releasebranch_6_4/dist.i686-pc-linux-gnu/etc/wxpython/gis_set.py
python -m py_compile /usr/local/src/grass/svn/releasebranch_6_4/dist.i686-pc-linux-gnu/etc/wxpython/wxgui.py
GISRC=/usr/local/src/grass/svn/releasebranch_6_4/dist.i686-pc-linux-gnu/demolocation/.grassrc64 GISBASE=/usr/local/src/grass/svn/releasebranch_6_4/dist.i68
6-pc-linux-gnu PATH="/usr/local/src/grass/svn/releasebranch_6_4/dist.i686-pc-linux-gnu/bin:$PATH" PYTHONPATH="/usr/local/src/grass/svn/releasebranch_6_4/di
st.i686-pc-linux-gnu/etc/python:$PYTHONPATH" LD_LIBRARY_PATH="/usr/local/src/grass/svn/releasebranch_6_4/dist.i686-pc-linux-gnu/bin:/usr/local/src/grass/sv
n/releasebranch_6_4/dist.i686-pc-linux-gnu/lib::" LC_ALL=C python core/menudata.py > menustrings.py
Traceback (most recent call last):
  File "core/menudata.py", line 39, in ?
    import wx
ImportError: No module named wx
make[2]: *** [menustrings.py] Error 1
make[2]: Leaving directory `/usr/local/src/grass/svn/releasebranch_6_4/gui/wxpython'
make[1]: Leaving directory `/usr/local/src/grass/svn/releasebranch_6_4/gui'
make[1]: Entering directory `/usr/local/src/grass/svn/releasebranch_6_4/imagery'
...

but after cd'ing into the dir and trying a second time it built ok.

note python was present on the system (see lack of errors about that in the above log snippet), I'm not sure what would happen if it wasn't installed, e.g. with the attempted byte compiling of lib/python/ and population of dist.arch/etc/python/grass/lib/. Probably you'd get a non-fatal error about it listed in error.log.

Hamish

[hamish]

note ./configure --help | less instructions:

  --with-python[=path/python-config]
                          enable support for wxGUI Python extensions
                          (python-config with path, e.g.
                          '--with-python=/usr/bin/python2.5-config',
                          default: no)
  --with-wxwidgets[=path/wx-config]
                          enable wxWidgets support (wx-config with path,
                          e.g. '--with-wxwidgets=/usr/local/bin/wx-config',
                          default: no)

[glynn]

Replying to hamish:

Is the goal to build on a system without any python on it, to build on a system without wxWidgets on it, or to just not build the wxGUI?

--with-python and --with-wxwidgets tell the configure script to check for Python/wxWidgets compilation/linking switches. These are only necessary if you're building binary modules (programs or shared libraries) which link against the Python or wx libraries (do any of these still exist? 7.0 has visualisation/wximgview, but that's largely obsoleted by scripts/wxpyimgview).

Note that neither switch is enabled by default, so there's no point in using --without-python or --without-wxwidgets.

If you enable the checks and they fail, configure will fail.

If it's just to avoid building with the wxGUI it's not really a problem, since most of it is not really built, just copied in place and then left unused.

Any Python modules and the wxGUI should be "built" regardless of whether Python and/or wxWidgets are installed on the build system.