On 2020/05/12 20:14, Daniel Shahaf wrote: > Branko Čibej wrote on Tue, 12 May 2020 07:48 +0200: >> On 11.05.2020 16:47, Daniel Shahaf wrote: >>> Yasuhito FUTATSUKI wrote on Mon, 11 May 2020 17:55 +0900: >>>> On 2020/05/10 1:39, Daniel Shahaf wrote: >>>>> A minor issue in current trunk: >>>>> >>>>> [[[ >>>>> % …/configure -q --enable-maintainer-mode --without-swig 'RUBY=none' >>>>> configure: WARNING: Python.h not found; disabling python swig bindings >>>>> ]]] >>>>> >>>>> That warning should not be printed when --without-swig is passed. >>>>> >>>>> It's printed by SVN_FIND_SWIG, which _does_ know whether that flag was >>>>> passed (it was passed iff «$where = no»), but I'm not sure what the >>>>> right fix is. >>>> I think it is not the problem of --without-swig option but the problem >>>> of usage of PYTHON environment variable, or how to specify the target >>>> of Python bindings. >>>> >>>> Even if users don't want to build Python bindings, they can't set >>>> 'PYTHON=none', like Ruby or Perl bindings. >>>> >>>> On the other hand, they can build Python bindings without SWIG, >>>> if there exists pre-generated bindings source files. >>> Makes sense. I guess we should add a --enable-swig-python argument, >>> then? >> >> >> We can build Perl and Ruby bindings without Swig, too, and there are no >> extra knobs there. > > On the contrary: «./configure RUBY=none» disables the analogous Ruby > warning. I understand from Yasuhito that PERL=none does the same for > Perl. > >> The --without-swig option just means "don't use swig", it doesn't >> mean "don't build bindings." The latter is covered by not running >> 'make swig-X'. > > Yes, forget about --without-swig; that was my mistake and a red > herring. The point is that there should be a way to tell configure > "I don't intend to build swig-py so don't warn me about those > dependencies being missing", like RUBY=none disables the "Ruby not > found" warning and --without-apxs disables the "apxs not found" warning. > > As Yasuhito said, passing PYTHON=none is not a satisfactory workaround > since it breaks «make check». Hence, I proposed adding a dedicated > knob. Do you see a better solution?
One of the solutions is to make an other variable to specifiy Python path for SWIG Python bindings, like TARGET_PYTHON or more good name. (I tried it for the purpose to enable build Python 2 and Python 3 bindings in a same build tree[1], though it used bad names for this purpose, PYTHON2 and PYTHON3) Additionally I think it is nice to add argument like --with-swig-python(=bindings target python path)|--without-swig-python --with-swig-ruby(=bindings targe ruby path)|--without-swig-ruby --with-swig-perl(=bindings target perl path)|--without-swig-perl I think symmetricalness of those options/variables are important, but I have no idea how to resolve of asymmetric of PERL, PYTHON, and RUBY variables. [1] https://lists.apache.org/thread.html/35029fedfead63c938bcb1b5463f18d56f5664d17e4e03889aeeebb1%40%3Cdev.subversion.apache.org%3E Cheers, -- Yasuhito FUTATSUKI <futat...@poem.co.jp>/<futat...@yf.bsdclub.org>
