You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Daniel Shahaf <d....@daniel.shahaf.name> on 2020/05/09 16:39:34 UTC
configure --without-swig warns when it shouldn't
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.
Cheers,
Daniel
Re: configure --without-swig warns when it shouldn't
Posted by Yasuhito FUTATSUKI <fu...@poem.co.jp>.
On 2020/06/01 16:41, Daniel Shahaf wrote:
> Yasuhito FUTATSUKI wrote on Sun, 31 May 2020 19:03 +0900:
>> On 2020/05/31 14:39, Yasuhito FUTATSUKI wrote:
>>>
>>> I updated the patch.
>>
>> I found that subversion/bindings/swig/INSTALL still containd
>> environment variable based methods, so I updated the
>> patch again.
>>
>> The difference from previous "fix_configure_patch2.txt" is following two
>> hanks for subversion/bindings/swig/INSTALL:
>
> "hunks" ☺
>
>> [[
>> @@ -209,10 +213,10 @@
>
> [filtered through «wdiff -d»]
>
>> * Perl
>>
>> Perl 5.8.0 is required. You can specify the perl binary by passing
>> [-PERL=/path/to/perl-]
>> {+--with-swig-perl=/path/to/perl+} as [-part-] {+an option+} of the configure command
>> in the top level of the Subversion source tree.
>
> This is grammatical as it stands, but I think s/an option of/an option to/
> would better capture the intended meaning.
Thank you for the review again.
>> I attached full diff, as fix_configure_patch3.txt.
>
> Looks good to me. Thanks!
I fixed the description pointed out above and commited in r1878379.
(And I'm waiting for the result of svn-bb-openbsd bot.)
Cheers,
--
Yasuhito FUTATSUKI <fu...@poem.co.jp>
Re: configure --without-swig warns when it shouldn't
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Yasuhito FUTATSUKI wrote on Sun, 31 May 2020 19:03 +0900:
> On 2020/05/31 14:39, Yasuhito FUTATSUKI wrote:
> >
> > I updated the patch.
>
> I found that subversion/bindings/swig/INSTALL still containd
> environment variable based methods, so I updated the
> patch again.
>
> The difference from previous "fix_configure_patch2.txt" is following two
> hanks for subversion/bindings/swig/INSTALL:
"hunks" ☺
> [[
> @@ -209,10 +213,10 @@
[filtered through «wdiff -d»]
> * Perl
>
> Perl 5.8.0 is required. You can specify the perl binary by passing
> [-PERL=/path/to/perl-]
> {+--with-swig-perl=/path/to/perl+} as [-part-] {+an option+} of the configure command
> in the top level of the Subversion source tree.
This is grammatical as it stands, but I think s/an option of/an option to/
would better capture the intended meaning.
> I attached full diff, as fix_configure_patch3.txt.
Looks good to me. Thanks!
Daniel
Re: configure --without-swig warns when it shouldn't
Posted by Yasuhito FUTATSUKI <fu...@poem.co.jp>.
On 2020/05/31 14:39, Yasuhito FUTATSUKI wrote:
>
> I updated the patch.
I found that subversion/bindings/swig/INSTALL still containd
environment variable based methods, so I updated the
patch again.
The difference from previous "fix_configure_patch2.txt" is following two
hanks for subversion/bindings/swig/INSTALL:
[[
@@ -209,10 +213,10 @@
* Perl
Perl 5.8.0 is required. You can specify the perl binary by passing
- PERL=/path/to/perl as part of the configure command in the top level
- of the Subversion source tree. Make sure that the Perl version used
- is the same one that you configured SWIG to run against during the
- SWIG configure (see above).
+ --with-swig-perl=/path/to/perl as an option of the configure command
+ in the top level of the Subversion source tree. Make sure that the
+ Perl version used is the same one that you configured SWIG to run
+ against during the SWIG configure (see above).
1. Run `make swig-pl' from the top of the Subversion build tree.
@@ -251,10 +255,11 @@
3. To install, run `make install-swig-rb' from the top of the
Subversion build tree.
- You can specify the ruby binary by passing RUBY=/path/to/ruby as part
- of the configure command in the top level of the Subversion source
- tree. Make sure that the Ruby version used is the same one that you
- configured SWIG to run against during the SWIG configure (see above).
+ You can specify the ruby binary by passing --with-swig-ruby=/path/to/ruby
+ as an option of the configure command in the top level of the
+ Subversion source tree. Make sure that the Ruby version used is
+ the same one that you configured SWIG to run against during the
+ SWIG configure (see above).
BUILDING SWIG BINDINGS FOR SVN ON WINDOWS
]]
I attached full diff, as fix_configure_patch3.txt.
Thanks,
--
Yasuhito FUTATSUKI <fu...@yf.bsdclub.org>
Re: configure --without-swig warns when it shouldn't
Posted by Yasuhito FUTATSUKI <fu...@poem.co.jp>.
On 2020/05/31 12:14, Daniel Shahaf wrote:
> Yasuhito FUTATSUKI wrote on Sat, 30 May 2020 19:24 +0900:
>> On 2020/05/12 23:17, Branko Čibej wrote:
>>> 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 for the patch!
>
> I've tested it and confirm it behaves as expected:
>
> % ~/src/svn-config.nice ~/src/svn/t1 --without-apxs --without-swig-python
> % grep PYTHON Makefile | vipe
> PYTHON = python
> SWIG_PY_PYTHON = none
> %
Thank you for the review and confirmation.
> Just one question; see below.
>
> Yasuhito FUTATSUKI wrote on Sat, 30 May 2020 19:24 +0900:
>> +++ configure.ac (working copy)
>> @@ -1272,19 +1272,19 @@
>>
>> # Scripting and Bindings languages
>>
>> -# Python: Used for testsuite, and bindings
>> +# Python: Used for testsuite
>> AC_ARG_VAR([PYTHON], [Python interpreter command])
>>
>> PYTHON="`$abs_srcdir/build/find_python.sh`"
>> if test -z "$PYTHON"; then
>> - AC_MSG_WARN([Python 2.7 or later is required to run the testsuite])
>> - AC_MSG_WARN([or to use the Subversion Python bindings])
>> + AC_MSG_WARN([Python 2.7 or later is required to run the testsuite.])
>> AC_MSG_WARN([])
>> AC_MSG_WARN([If you have a suitable Python installed, but not on the])
>> AC_MSG_WARN([PATH, set the environment variable PYTHON to the full path])
>> AC_MSG_WARN([to the Python executable, and re-run configure])
>> + PYTHON=none
>> fi
>> -AC_PATH_PROGS(PYTHON, "$PYTHON", none)
>> +AC_SUBST(PYTHON)
>>
>
> Here configure sets PYTHON=none…
>
>> @@ -1291,16 +1291,95 @@
>> +# Python: as a target of SWIG Python bindings
>> +AC_ARG_WITH(swig_python,
>> +[AS_HELP_STRING([[--with-swig-python[=PATH|auto|no]|--without-swig-python]],
>> + [specify path to SWIG bindings target Python [default=auto]])],
>> +[],
>> +[
>> +if test "$PYTHON" = "no" -o "$PYTHON" = "none"; then
>> + with_swig_python=no
>> + AC_MSG_WARN([Disabling build of SWIG Python bindings by setting "none" to])
>> + AC_MSG_WARN([PYTHON envirionment variable is deprecated.])
>> + AC_MSG_WARN([])
>> + AC_MSG_WARN([Please use --without-swig-python instead.])
>
> …and here configure warns when $PYTHON is set to «none». Would this
> error message be printed when the value «none» was set by configure,
> above, rather than by the user?
Sure.
Moreover, $PYTHON in this context is always set by the find_python.sh
script except "none" set by above substitution in 'if test -z "$PYTHON"'
block. That is to say, without this patch, it is needed to hide Python
interpreter from the find_python.sh script to avoid check for SWIG
Python bindings.
Now I think this warning message itself means nothing, so I dropped
this warning for SWIG Python bindings.
> ---
>
> Some suggested changes to the English:
>
Thank you very much.
I updated the patch.
Thanks,
--
Yasuhito FUTATSUKI <fu...@yf.bsdclub.org>
Re: configure --without-swig warns when it shouldn't
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Yasuhito FUTATSUKI wrote on Sat, 30 May 2020 19:24 +0900:
> On 2020/05/12 23:17, Branko Čibej wrote:
> > 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 for the patch!
I've tested it and confirm it behaves as expected:
% ~/src/svn-config.nice ~/src/svn/t1 --without-apxs --without-swig-python
% grep PYTHON Makefile | vipe
PYTHON = python
SWIG_PY_PYTHON = none
%
Just one question; see below.
Yasuhito FUTATSUKI wrote on Sat, 30 May 2020 19:24 +0900:
> +++ configure.ac (working copy)
> @@ -1272,19 +1272,19 @@
>
> # Scripting and Bindings languages
>
> -# Python: Used for testsuite, and bindings
> +# Python: Used for testsuite
> AC_ARG_VAR([PYTHON], [Python interpreter command])
>
> PYTHON="`$abs_srcdir/build/find_python.sh`"
> if test -z "$PYTHON"; then
> - AC_MSG_WARN([Python 2.7 or later is required to run the testsuite])
> - AC_MSG_WARN([or to use the Subversion Python bindings])
> + AC_MSG_WARN([Python 2.7 or later is required to run the testsuite.])
> AC_MSG_WARN([])
> AC_MSG_WARN([If you have a suitable Python installed, but not on the])
> AC_MSG_WARN([PATH, set the environment variable PYTHON to the full path])
> AC_MSG_WARN([to the Python executable, and re-run configure])
> + PYTHON=none
> fi
> -AC_PATH_PROGS(PYTHON, "$PYTHON", none)
> +AC_SUBST(PYTHON)
>
Here configure sets PYTHON=none…
> @@ -1291,16 +1291,95 @@
> +# Python: as a target of SWIG Python bindings
> +AC_ARG_WITH(swig_python,
> +[AS_HELP_STRING([[--with-swig-python[=PATH|auto|no]|--without-swig-python]],
> + [specify path to SWIG bindings target Python [default=auto]])],
> +[],
> +[
> +if test "$PYTHON" = "no" -o "$PYTHON" = "none"; then
> + with_swig_python=no
> + AC_MSG_WARN([Disabling build of SWIG Python bindings by setting "none" to])
> + AC_MSG_WARN([PYTHON envirionment variable is deprecated.])
> + AC_MSG_WARN([])
> + AC_MSG_WARN([Please use --without-swig-python instead.])
…and here configure warns when $PYTHON is set to «none». Would this
error message be printed when the value «none» was set by configure,
above, rather than by the user?
---
Some suggested changes to the English:
Yasuhito FUTATSUKI wrote on Sat, 30 May 2020 19:24 +0900:
> configure: Add new option to specify path to swig bindings targets
>
> Before this commit, we could not distinct Python processor for using
> as a part of build/test system and for a target of language bindings.
"distinct" is an adjective, not a verb, and "processor" as a term of
art has specific meanings which don't fit this context, so how about:
Before this commit, it was not possible to use distinct Python
installations for the build system and test suite on the one hand,
and for building language bindings against on the other hand.
That's a little wordy because of the "and" in "the build system and test
suite".
I've changed the use of "target" because, in this context, I'd say the
"target" of, say, the SWIG Python bindings is the range of Python
versions they are intended to support, rather than any particular
Python installation.
> So we've introduced new variable "SWIG_PY_PYTHON" for a target of
> the SWIG Python bindings and configure option to specify it.
> Also, for the symmetricalness we've introduced "SWIG_PL_PERL" and
> "SWIG_RB_RUBY" for the Perl and Ruby SWIG bindings, and options
> to specify them.
By convention, log messages should use the imperative mood to describe
the changes their patches make; thus, s/we've introduced/introduce/.
Some projects follow another convention and use the past tense (e.g.,
"Fixed bug #42"). In contrast, as written (in present perfect) it
could be understood as describing for the reader the historical context
of the patch, as opposed to describing the changes made by the patch.
Furthermore:
s/configure option/a configure option/
s/symmetricalness/symmetry/
> * configure.ac ():
> - Use variables "SWIG_PL_PERL", "SWIG_PY_PYTHON", "SWIG_RB_RUBY" for
> target of SWIG Perl, Python, Ruby bindings instead of "PERL",
> "PYTHON", "RUBY".
> - introduce --with-swig-perl, --with-swig-python, --with-swig-ruby
> options for setting variable "SWIG_PL_PERL", "SWIG_PY_PYTHON",
> "SWIG_RB_RUBY".
"Introduce" should be capitalized like "Use" is: each of those words
is at the start of a sentence. There's another case of this later in
the log message.
> * Makefile.in, build/ac-macros/swig.m4 ():
> Use variables "SWIG_PL_PERL", "SWIG_PY_PYTHON", "SWIG_RB_RUBY" for
> target of SWIG Perl, Python, Ruby bindings instead of "PERL",
> "PYTHON", "RUBY".
>
> * subversion/bindings/swig/INSTALL
> (BUILDING SWIG BINDINGS FOR SVN ON UNIX step 2):
> - Describe how to specify the path to the target language interpreters
> with new introduced options, instead of using environment variable.
"with new introduced options" lacks a definite article (the options are
already known to the reader). Furthermore, "new introduced" is
a sequence of two adjectives with no intervening comma, which isn't
necessarily appropriate in this context. All in all, I'd suggest
"with the new options" or "with the newly-introduced options".
"environment variables" should be plural.
> - fix the name of glue libraries.
> +++ configure.ac (working copy)
> @@ -1291,16 +1291,95 @@
> # SVN_CHECK_JDK sets $JAVA_CLASSPATH
> SVN_CHECK_JDK($JAVA_OLDEST_WORKING_VER)
>
> -AC_PATH_PROG(PERL, perl, none)
> +AC_ARG_WITH(swig_perl,
> +[AS_HELP_STRING([[--with-swig-perl[=PATH|auto|no]|--without-swig-perl]],
> + [specify path to SWIG bindings target Perl [default=auto]])],
How about s/Perl/Perl interpreter/, so it's clear which path should be
specified as the argument to this option?
Likewise for the other new options' help strings.
> +[],
> +[
> +if test "$PERL" = "no" -o "$PERL" = "none"; then
> + with_swig_perl=no
> + AC_MSG_WARN([Disabling build of SWIG Perl bindings by setting "none" to])
> + AC_MSG_WARN([PERL envirionment variable is deprecated.])
«by setting the PERL environment variable to "none"». (Change the word
order, add missing definite article, and correct the spelling of "environment".)
s/build/building/ [or "Disabling the SWIG Perl bindings' build"]
> + AC_MSG_WARN([])
> + AC_MSG_WARN([Please use --without-swig-perl instead.])
Thanks again,
Daniel
Re: configure --without-swig warns when it shouldn't
Posted by Yasuhito FUTATSUKI <fu...@poem.co.jp>.
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 <fu...@yf.bsdclub.org>
Re: configure --without-swig warns when it shouldn't
Posted by Branko Čibej <br...@apache.org>.
On 12.05.2020 15:05, Yasuhito FUTATSUKI wrote:
> 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.
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.
-- Brane
Re: configure --without-swig warns when it shouldn't
Posted by Yasuhito FUTATSUKI <fu...@poem.co.jp>.
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 <fu...@yf.bsdclub.org>
Re: configure --without-swig warns when it shouldn't
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
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?
Cheers,
Daniel
Re: configure --without-swig warns when it shouldn't
Posted by Branko Čibej <br...@apache.org>.
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. 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'.
-- Brane
Re: configure --without-swig warns when it shouldn't
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
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?
Cheers,
Daniel
Re: configure --without-swig warns when it shouldn't
Posted by Yasuhito FUTATSUKI <fu...@poem.co.jp>.
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.
Cheers,
--
Yasuhito FUTATSUKI <fu...@poem.co.jp>