automake-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] {maint} python: extend and improve tests, fix minor glitches


From: Stefano Lattarini
Subject: Re: [PATCH] {maint} python: extend and improve tests, fix minor glitches
Date: Thu, 10 Feb 2011 10:33:30 +0100
User-agent: KMail/1.13.3 (Linux/2.6.30-2-686; KDE/4.4.4; i686; ; )

On Wednesday 09 February 2011, Ralf Wildenhues wrote:
> Hi Stefano,
> 
> * Stefano Lattarini wrote on Sun, Feb 06, 2011 at 06:32:56PM CET:
> > Hello Ralf, and sorry for the delay.
> 
> No worries.  I'm waay more behind.
> 
> > On Thursday 03 February 2011, Ralf Wildenhues wrote:
> > > * Stefano Lattarini wrote on Wed, Feb 02, 2011 at 12:10:15AM CET:
> > > > A testsuite-enhancement patch stemmed from my brief foray into
> > > > Automake's python support.  This patch is in small part cosmetic,
> > > > but IMHO offers real improvements and valuable additions, and
> > > > also fixes a couple of glitches in python.m4.
> > > 
> > > OK for master (branched off of maint, if you prefer) with nits
> > > addressed.
> > >
I've now merged to patch (branched off of maint) into master, and pushed.

> > > Before pushing, please test on a system without a python interpreter
> > > installed (you can rename you pythons temporarily).
> > >
> > Nah, IMHO is better to do something like:
> > 
> >   $ cd ~/src/automake/tests
> >   $ mkdir xbin && cd xbin
> >   $ for f in /bin/* /usr/bin/* /usr/local/bin/*; do
> >   >   case $f in *python*);; *) ln -s $f .;; esac
> >   > done
> >   $ cd ..
> >   $ PATH=`pwd`/xbin make check TESTS='...'
> 
> Neat; but also expensive.
>
Ah, but botching up system-wide python is much more expensive.
And Murphy is always lurking ... ;-)

> [CUT]

> > > > --- a/tests/python5.test
> > > > +++ b/tests/python5.test
> > > 
> > > > @@ -24,16 +24,32 @@ set -e
> > > >  
> > > >  cat >>configure.in <<EOF
> > > >  # Hopefully the Python team will never release such a version.
> > > > -AM_PATH_PYTHON(9999.9)
> > > > +AM_PATH_PYTHON([9999.9])
> > > 
> > > Nice that you do it here, but up in python.m4 you should then, too.
> > >
> > Definitely.  But in a follow-up patch IMHO (and since we are at it, we
> > should fix underquoting in all the other *.m4 automake files).  I will
> > submit this patch in the coming week.
> 
> OK.
>
Patch still on the todo list ...

> > Attached is what I've squashed into the previous version of the patch.
> > 
> > I will push in 72 hours if there are no further objections.
> 
> OK but I have a question below.
> 
> > --- a/tests/instdir-ltlib.test
> > +++ b/tests/instdir-ltlib.test
> 
> > @@ -14,7 +14,8 @@
> >  # You should have received a copy of the GNU General Public License
> >  # along with this program.  If not, see <http://www.gnu.org/licenses/>.
> >  
> > -# If $(libdir) is the empty string, then nothing should be installed there.
> > +# If $(libdir) or $(pyexecdir) is the empty string, then nothing should
> > +# be installed there.
> >  # This test exercises the libtool code paths.
> >  
> >  required=libtoolize
> > @@ -26,6 +27,7 @@ cat >>configure.in <<'END'
> >  AC_PROG_CC
> >  AM_PROG_CC_C_O
> >  AC_PROG_LIBTOOL
> > +AM_PATH_PYTHON
> >  AC_OUTPUT
> >  END
> >   
> 
> > --- a/tests/instdir-prog.test
> > +++ b/tests/instdir-prog.test
> 
> > @@ -14,7 +14,8 @@
> >  # You should have received a copy of the GNU General Public License
> >  # along with this program.  If not, see <http://www.gnu.org/licenses/>.
> >  
> > -# If $(bindir) is the empty string, then nothing should be installed there.
> > +# If $(bindir), $(libdir) or $(pyexecdir) is the empty string, then
> > +# nothing should be installed there.
> >  # This test exercises the prog and libs code paths.
> >  
> >  . ./defs || Exit 1
> > @@ -25,6 +26,7 @@ cat >>configure.in <<'END'
> >  AC_PROG_CC
> >  AM_PROG_CC_C_O
> >  AC_PROG_RANLIB
> > +AM_PATH_PYTHON
> >  AC_OUTPUT
> >  END
> >  
> 
> Do these two tests require python now?
>
No, since I define the relevant configure cache values explicitly,
and also force PYTHON to `echo'.  Also, making such important and
generic tests depend on python would have been a royally bad idea.

> In that case maybe the merging
> wasn't such a good idea after all; several of the machines I
> test on do not have python in the default PATH.
>
In light of the above, this shouldn't be a problem.

Regards,
   Stefano



reply via email to

[Prev in Thread] Current Thread [Next in Thread]