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 <futatuki_at_poem.co.jp>/<futatuki_at_yf.bsdclub.org>
Received on 2020-05-12 15:06:35 CEST