On 2020/05/12 23:17, Branko Čibej wrote:
> On 12.05.2020 15:05, Yasuhito FUTATSUKI wrote:
>> On 2020/05/12 20:14, Daniel Shahaf wrote:
>>> 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.
>
>
> Can we just say that it was a mistake to look at the environment (e.g.,
> PERL=none) instead of configure arguments (--without-swig-perl)? I agree
> that adding the proposed flags to configure is the correct solution. We
> could also add a warning for usage of PERL=none and RUBY=none, pointing
> users to the new options instead.
Then I make a patch as a starting point. Could anyone please refine
or rewrite this?
Thanks,
--
Yasuhito FUTATSUKI <futatuki_at_poem.co.jp>/<futatuki_at_yf.bsdclub.org>
Received on 2020-05-30 12:25:40 CEST