Vladimir Volovich | 4 Feb 2007 11:20
Picon

Re: xindy-2.2_beta2-r2.ebuild for Gentoo

"JS" == Joachim Schrod writes:

 VV> i didn't see your reply to Gour with the "available
 VV> patches". Could you post them here?

 JS> Below.

thanks. could you also upload the xindy-2.2-rc3 tarball?
nothing prevents you to release rc4, if needed, before the final release.

Best,
v.

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
Jörg Sommer | 5 Feb 2007 22:56
Picon

Request: New beta release

Hi Joachim,

Vladimir Volovich schrieb am Sun 04. Feb, 13:20 (+0300):
> "JS" == Joachim Schrod writes:
> 
>  VV> i didn't see your reply to Gour with the "available
>  VV> patches". Could you post them here?
> 
>  JS> Below.
> 
> thanks. could you also upload the xindy-2.2-rc3 tarball?
> nothing prevents you to release rc4, if needed, before the final release.

I second this request. IMO you've added so much patches that a new beta
release is it worth.

Kind regards, Jörg.
--

-- 
Macht besitzen und nicht ausüben ist wahre Größe.
                                                   (Friedl Beutelrock)
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
(Continue reading)

Joachim Schrod | 12 Feb 2007 01:17
Picon
Favicon

Re: Request: New beta release

>>>>> "JS" == Jörg Sommer <joerg <at> alea.gnuu.de> writes:
JS> Vladimir Volovich schrieb am Sun 04. Feb, 13:20 (+0300):
>> 
>> thanks. could you also upload the xindy-2.2-rc3 tarball?
>> nothing prevents you to release rc4, if needed, before the final release.

JS> I second this request. IMO you've added so much patches that a new
JS> beta release is it worth.

The following showstopper issues are still open:

 -- Compilation with gcc 4 does not work [bug ticket 1515980]
 -- Update README
 -- Update installation instruction
    Beyond the usual configure blurb, outline the dependency on a
    working TeX installation (for make-rules) and the incompatible
    directory layout compared to previous distributions (relevant for
    locally installed xindy modules).
 -- Update NEWS file
 -- Add AUTHORS / copyright information
 -- Generate missing $libdir/VERSION file to identify distribution
    release, also used by internal code.

The first issue means that the rc3 tarball does not even compile on my
own system; thus I really don't think that it's sensible to release it.

And if Jörg could explain more about the AM_MAINTAINER_MODE change
that he requested and that Gour rejected in his email from Sep 2006,
with a link to statements from the automake and autoconf mailing list,
I would be grateful as well.
(Continue reading)

Gour | 4 Mar 2007 11:19
X-Face

Re: Request: New beta release

On Mon, 12 Feb 2007 01:17:15 +0100
Joachim Schrod <jschrod <at> acm.org> wrote:

Hi!

> The following showstopper issues are still open:
> 
>  -- Compilation with gcc 4 does not work [bug ticket 1515980]

Today I tried to build xindy and compilation fails indeed.

However, I've the same issue with compiling clisp-2.41 as well...

I'll watch Gentoo's bug to see how it will resolve, but I vote for the
attempt to try to make xindy-release with clisp-2.41, if possible.

> The first issue means that the rc3 tarball does not even compile on my
> own system; thus I really don't think that it's sensible to release
> it.

I can help with the distribution issues when the clisp ones are
resolved.

Sincerely,
Gour

p.s. Pls. excuse me for late reply, but I'm behind my email a bit...
-------------------------------------------------------------------------
(Continue reading)

Vladimir Volovich | 4 Mar 2007 14:32
Picon

Re: Request: New beta release

"G" == Gour  writes:

 G> Today I tried to build xindy and compilation fails indeed.

are the problems caused by a compiler bug, perhaps? what is the error message?

 G> However, I've the same issue with compiling clisp-2.41 as well...

i don't have problems with GCC 4.1.2 - xindy builds fine (even with
the included clisp sources).

Best,
v.

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Gour | 4 Mar 2007 20:19
X-Face

Re: Request: New beta release

On Sun, 04 Mar 2007 16:32:14 +0300
Vladimir Volovich <vvv <at> vsu.ru> wrote:

> are the problems caused by a compiler bug, perhaps? what is the error
> message?

...
gmake[2]: Leaving directory
`/var/tmp/portage/dev-lisp/clisp-2.41/work/clisp-2.41/build/libcharset/lib' /bin/sh
../../libcharset/build-aux/mkinstalldirs /var/tmp/portage/dev-lisp/clisp-2.41/work/clisp-2.41/build
/usr/bin/install -c -m 644
include/libcharset.h
/var/tmp/portage/dev-lisp/clisp-2.41/work/clisp-2.41/build/libcharset.h /usr/bin/install
-c -m 644
include/localcharset.h /var/tmp/portage/dev-lisp/clisp-2.41/work/clisp-2.41/build/localcharset.h
gmake[1]: Leaving directory
`/var/tmp/portage/dev-lisp/clisp-2.41/work/clisp-2.41/build/libcharset'
gcc  -march=k8 -O2 -pipe -W -Wswitch -Wcomment -Wpointer-arith
-Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -O
-DUNICODE -DDYNAMIC_FFI -I. -c spvw.c In file included from
lispbibl.d:1979, from spvw.d:24: unix.d:178:56: error: asm/page.h: No
such file or directory make: *** [spvw.o] Error 1

> i don't have problems with GCC 4.1.2 - xindy builds fine (even with
> the included clisp sources).

Interesting...

In the upcoming week I'll try to take a closer look at the
issue...beta for lyx-1.5.0 is out bringing Unicode, so it would be nice
(Continue reading)

Jörg Sommer | 6 Mar 2007 16:14
Picon

Re: Request: New beta release

Hallo Gour,

Gour schrieb am Sun 04. Mar, 20:19 (+0100):
> On Sun, 04 Mar 2007 16:32:14 +0300
> Vladimir Volovich <vvv <at> vsu.ru> wrote:
> 
> > are the problems caused by a compiler bug, perhaps? what is the error
> > message?
> 
> ...
> gmake[2]: Leaving directory
> `/var/tmp/portage/dev-lisp/clisp-2.41/work/clisp-2.41/build/libcharset/lib' /bin/sh
../../libcharset/build-aux/mkinstalldirs /var/tmp/portage/dev-lisp/clisp-2.41/work/clisp-2.41/build
> /usr/bin/install -c -m 644
> include/libcharset.h
/var/tmp/portage/dev-lisp/clisp-2.41/work/clisp-2.41/build/libcharset.h /usr/bin/install
> -c -m 644
> include/localcharset.h /var/tmp/portage/dev-lisp/clisp-2.41/work/clisp-2.41/build/localcharset.h
> gmake[1]: Leaving directory
> `/var/tmp/portage/dev-lisp/clisp-2.41/work/clisp-2.41/build/libcharset'
> gcc  -march=k8 -O2 -pipe -W -Wswitch -Wcomment -Wpointer-arith
> -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -O
> -DUNICODE -DDYNAMIC_FFI -I. -c spvw.c In file included from
> lispbibl.d:1979, from spvw.d:24: unix.d:178:56: error: asm/page.h: No
> such file or directory make: *** [spvw.o] Error 1

Maybe the build log from the debian package helps you:
http://buildd.debian.org/fetch.cgi?pkg=clisp;ver=1%3A2.41-1;arch=amd64;stamp=1161063779

Schöne Grüße, Jörg.
(Continue reading)

Vladimir Volovich | 6 Mar 2007 08:27
Picon

Re: Request: New beta release

"G" == Gour  writes:

 G> unix.d:178:56: error: asm/page.h: No such file or directory

are you building on linux? do you have the linux-kernel-headers
package installed (or it may be named differently in your
distribution)?

the error message you cited looks like caused by absent system headers.
it doesn't look like dependent on compiler version.

Best,
v.

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Gour | 6 Mar 2007 15:36
X-Face

Re: Request: New beta release

On Tue, 06 Mar 2007 10:27:48 +0300
Vladimir Volovich <vvv <at> vsu.ru> wrote:

> are you building on linux? 

Yes.

> do you have the linux-kernel-headers package installed (or it may be
> named differently in your distribution)?

Yes, I'm on Gentoo, so everything is built from the source ;)

> the error message you cited looks like caused by absent system
> headers. it doesn't look like dependent on compiler version.

I'll investigate a bit...

Sincerely,
Gour
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
(Continue reading)

Jörg Sommer | 24 Feb 2007 00:21
Picon

Re: Request: New beta release

Hi Joachim,

Joachim Schrod schrieb am Mon 12. Feb, 01:17 (+0100):
> >>>>> "JS" == Jörg Sommer <joerg <at> alea.gnuu.de> writes:
> JS> Vladimir Volovich schrieb am Sun 04. Feb, 13:20 (+0300):
> >> 
> >> thanks. could you also upload the xindy-2.2-rc3 tarball?
> >> nothing prevents you to release rc4, if needed, before the final release.
> 
> JS> I second this request. IMO you've added so much patches that a new
> JS> beta release is it worth.
> 
> The following showstopper issues are still open:
> 
>  -- Compilation with gcc 4 does not work [bug ticket 1515980]
> 
> The first issue means that the rc3 tarball does not even compile on my
> own system; thus I really don't think that it's sensible to release it.

Can you compile CLISP 2.41? Can you compile xindy with this version if
you apply the following patch?

#! /bin/sh /usr/share/dpatch/dpatch-run
## fix-errors.dpatch by Jörg Sommer <joerg <at> alea.gnuu.de>
##
## DP: With the usage of the clisp package (version 2.38) you get some errors:
## DP: 1. xindy fails with
## DP:       MAKE-PATHNAME: illegal :DIRECTORY argument (".")
## DP:    I don't know why. My presumption is that somewhere between version
## DP:    2.33.2 (the version shipped with the source) and 2.38 the function
(Continue reading)

Joachim Schrod | 27 Feb 2007 02:15
Picon
Favicon

Re: Request: New beta release

>>>>> "JS" == Jörg Sommer <joerg <at> alea.gnuu.de> writes:

>> And if Jörg could explain more about the AM_MAINTAINER_MODE change
>> that he requested and that Gour rejected in his email from Sep 2006,
>> with a link to statements from the automake and autoconf mailing list,
>> I would be grateful as well.

JS> The problem with an automatic maintainer mode is that before
JS> building starts it's checked if a newer version of the autotools
JS> is installed. If yes all configure and Makefile.in files are
JS> rebuild which leads to the problem that they are not the same as
JS> the ones shipped with the source. This might introduce differences
JS> which are hard to find.

I tried to understand this, but did not succeed, and need more
information; sorry.

If I understand you correctly, either configure or make checks if a
newer version of autotools is available and, in that case, creates
configure and Makefile.in anew from configure.ac and Makefile.am.

I tried to see where it does so. The Makefile has no such
dependencies, neither for configure nor for Makefile.in. Everything
depends on the local m4 files from the distribution. Thus it must be
configure who does the misdeed.

A `grep -i autoconf conf*' did also not show any places where the
autotools version is checked. Nor did a grep on 2.59 or on version or
any other string that I could think of.

(Continue reading)

Jörg Sommer | 27 Feb 2007 13:18
Picon

Re: Request: New beta release

Hi,

Joachim Schrod schrieb am Tue 27. Feb, 02:15 (+0100):
> >>>>> "JS" == Jörg Sommer <joerg <at> alea.gnuu.de> writes:
> 
> >> And if Jörg could explain more about the AM_MAINTAINER_MODE change
> >> that he requested and that Gour rejected in his email from Sep 2006,
> >> with a link to statements from the automake and autoconf mailing list,
> >> I would be grateful as well.
> 
> JS> The problem with an automatic maintainer mode is that before
> JS> building starts it's checked if a newer version of the autotools
> JS> is installed. If yes all configure and Makefile.in files are
> JS> rebuild which leads to the problem that they are not the same as
> JS> the ones shipped with the source. This might introduce differences
> JS> which are hard to find.
> 
> I tried to understand this, but did not succeed, and need more
> information; sorry.
> 
> If I understand you correctly, either configure or make checks if a
> newer version of autotools is available and, in that case, creates
> configure and Makefile.in anew from configure.ac and Makefile.am.

Yes, correct.

> I tried to see where it does so. The Makefile has no such
> dependencies, neither for configure nor for Makefile.in. Everything
> depends on the local m4 files from the distribution. Thus it must be
> configure who does the misdeed.
(Continue reading)

Joachim Schrod | 28 Feb 2007 10:57
Picon
Favicon

Re: Request: New beta release

>>>>> "JS" == Jörg Sommer <joerg <at> alea.gnuu.de> writes:

JS> No, the Makefile includes a call of missing. That checks for newer tools
JS> and runs them if requisite.

JS> % grep missing /tmp/xindy-2.2-beta2/Makefile
JS>         install-sh missing
JS> ACLOCAL = ${SHELL} /tmp/xindy-2.2-beta2/missing --run aclocal-1.9
JS> AMTAR = ${SHELL} /tmp/xindy-2.2-beta2/missing --run tar
JS> AUTOCONF = ${SHELL} /tmp/xindy-2.2-beta2/missing --run autoconf
JS> AUTOHEADER = ${SHELL} /tmp/xindy-2.2-beta2/missing --run autoheader
JS> AUTOMAKE = ${SHELL} /tmp/xindy-2.2-beta2/missing --run automake-1.9
JS> MAKEINFO = ${SHELL} /tmp/xindy-2.2-beta2/missing --run makeinfo

Sorry, but I still can't see the reason for the described behavior.

The first line is not a call, but the definition of the macro
DIST_COMMON. That macro is used in the definition of DISTFILES; and
DISTFILES is only used as dependency in distdir. No call of missing in
there.

The other lines are definitions of Make variables. These variables are
only used in actions that are triggered when local (distributed!)
files change; notably when the *.{m4,ac,am} files are newer than the
generated files. I found no other usage of these files. And in the
distributed beta2 archive, the {configure,Makefile.in} files are newer
than {configure.ac,Makefile.am}.

JS> This leads to

(Continue reading)

Jörg Sommer | 28 Feb 2007 15:08
Picon

Re: Request: New beta release

Hallo,

Joachim Schrod schrieb am Wed 28. Feb, 10:57 (+0100):
> >>>>> "JS" == Jörg Sommer <joerg <at> alea.gnuu.de> writes:
> 
> These variables are only used in actions that are triggered when local
> (distributed!) files change; notably when the *.{m4,ac,am} files are
> newer than the generated files. I found no other usage of these files.
> And in the distributed beta2 archive, the {configure,Makefile.in} files
> are newer than {configure.ac,Makefile.am}.

If you run make with -d, you can see what he is doing. But I didn't
understand, why it does it.

> JS> This leads to
> 
> JS> % tar -xzf ~/dl/xindy-2.2-beta2.tar.gz 
> JS> % cp -r xindy-2.2-beta2 xindy-2.2-beta2.orig
> JS> % cd xindy-2.2-beta2
> JS> xindy-2.2-beta2% ./configure; make; make distclean
> JS> […]
> JS> % cd ..
> JS> % diff -r -U0 xindy-2.2-beta2 xindy-2.2-beta2.orig | wc -l
> JS> 11701
> 
> Can you please do a diff -r --brief, so that I can see what files have
> changed?

Oh, I didn't know that diff prints the files names when called with -q.

(Continue reading)

Vladimir Volovich | 28 Feb 2007 18:00
Picon

Re: Request: New beta release

"JS" == Jörg Sommer writes:

 >> These variables are only used in actions that are triggered when
 >> local (distributed!) files change; notably when the *.{m4,ac,am}
 >> files are newer than the generated files. I found no other usage
 >> of these files.  And in the distributed beta2 archive, the
 >> {configure,Makefile.in} files are newer than
 >> {configure.ac,Makefile.am}.

 JS> If you run make with -d, you can see what he is doing. But I
 JS> didn't understand, why it does it.

OK, i've debugged this. there are dependencies in the Makefile which
lead to regeneration of aclocal.m4, Makefile.in and configure because
of wrong timestamps.

to prevent these regenerations, you need to:
* first touch all aclocal.m4 files
* then  touch all Makefile.in files
* then  touch all configure files

here is what i get:

$ tar xfz ~/src/xindy/xindy-2.2-beta2.tar.gz
$ cp -a xindy-2.2-beta2 xindy-2.2-beta2.orig
$ cd xindy-2.2-beta2
$ touch `find . -name aclocal.m4`
$ sleep 2
$ touch `find . -name Makefile.in`
$ sleep 2
(Continue reading)

Jörg Sommer | 1 Mar 2007 17:06
Picon

Re: Request: New beta release

Hi Vladimir,

Vladimir Volovich schrieb am Wed 28. Feb, 20:00 (+0300):
> "JS" == Jörg Sommer writes:
> 
>  >> These variables are only used in actions that are triggered when
>  >> local (distributed!) files change; notably when the *.{m4,ac,am}
>  >> files are newer than the generated files. I found no other usage
>  >> of these files.  And in the distributed beta2 archive, the
>  >> {configure,Makefile.in} files are newer than
>  >> {configure.ac,Makefile.am}.
> 
>  JS> If you run make with -d, you can see what he is doing. But I
>  JS> didn't understand, why it does it.
> 
> OK, i've debugged this. there are dependencies in the Makefile which
> lead to regeneration of aclocal.m4, Makefile.in and configure because
> of wrong timestamps.
> 
> to prevent these regenerations, you need to:
> * first touch all aclocal.m4 files
> * then  touch all Makefile.in files
> * then  touch all configure files

I tried it and it works. The problem are be the time stamps in the
archive. I changed my debian/rules files and do a new upload next week.

> $ tar xfz ~/src/xindy/xindy-2.2-beta2.tar.gz
> $ cp -a xindy-2.2-beta2 xindy-2.2-beta2.orig
> $ cd xindy-2.2-beta2
(Continue reading)

Vladimir Volovich | 1 Mar 2007 17:22
Picon

Re: Request: New beta release

"JS" == Jörg Sommer writes:

 >> $ touch `find . -name aclocal.m4`
 >> $ sleep 2

 JS> touch has the option -d to give it a different time stamp than
 JS> now.

yes, but which specific date to put there? it was easier to put
current timestamp. it should be done once in the source tarball,
anyway (and upon further development, the timestamps should be
correct, if one always reautoconfs the sources after e.g. changing
Makefile.am).

 >> The file xindy-2.2-beta2/rte/clisp-2.33.2/src/Makefile~ is not
 >> removed

 JS> Where does it come from? I don't have this file.

This Makefile~ is generated by a rule in
xindy-2.2-beta2/rte/clisp-2.33.2/src/Makefile which is generated from
xindy-2.2-beta2/rte/clisp-2.33.2/src/makemake.in (look there for
"Makefile~").

Best,
v.

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
(Continue reading)

Jörg Sommer | 24 Feb 2007 00:30
Picon

Re: Request: New beta release

Hello,

Jörg Sommer schrieb am Sat 24. Feb, 00:21 (+0100):
> Joachim Schrod schrieb am Mon 12. Feb, 01:17 (+0100):
> > And if Jörg could explain more about the AM_MAINTAINER_MODE change
> > that he requested and that Gour rejected in his email from Sep 2006,
> > with a link to statements from the automake and autoconf mailing list,
> > I would be grateful as well.
> 
> The problem with an automatic maintainer mode is that before building
> starts it's checked if a newer version of the autotools is installed. If
> yes all configure and Makefile.in files are rebuild which leads to the
> problem that they are not the same as the ones shipped with the source.
> This might introduce differences which are hard to find.

And I've another big problem: I can't reset the build tree to the state
before calling configure, or it's hard to do so.

Bye, Jörg.
--

-- 
Im Leben lernt der Mensch als erstes das Gehen und Sprechen.
Später lernt er still zu sitzen und den Mund zu halten.
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
(Continue reading)

Joachim Schrod | 27 Feb 2007 02:20
Picon
Favicon

Re: Request: New beta release


>> > And if Jörg could explain more about the AM_MAINTAINER_MODE change
>> > that he requested and that Gour rejected in his email from Sep 2006,
>> > with a link to statements from the automake and autoconf mailing list,
>> > I would be grateful as well.
>> 
>> The problem with an automatic maintainer mode is that before building
>> starts it's checked if a newer version of the autotools is installed. If
>> yes all configure and Makefile.in files are rebuild which leads to the
>> problem that they are not the same as the ones shipped with the source.
>> This might introduce differences which are hard to find.

JS> And I've another big problem: I can't reset the build tree to the
JS> state before calling configure, or it's hard to do so.

Do you mean that "make distclean" does not work?
Which files are not deleted?

	Joachim

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod			Email: jschrod <at> acm.org
xindy maintainer		http://www.xindy.org/
Roedermark, Germany

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
(Continue reading)

Vladimir Volovich | 12 Feb 2007 09:58
Picon

Re: Request: New beta release

"JS" == Joachim Schrod writes:

 JS>  -- Compilation with gcc 4 does not work [bug ticket 1515980]
[...]
 JS> The first issue means that the rc3 tarball does not even compile
 JS> on my own system; thus I really don't think that it's sensible to
 JS> release it.

it looks like a problem with compiling an outdated version of clisp
(2.25.1) included into xindy, using GCC 4.0.

it looks like a bug in either GCC 4.0, because earlier versions
compile OK.

if it's caused by a bug in GCC, why is it a show-stopper for another
xindy PRE-release? not even a "final" release, just another PRE-release.

also, someone asked:

> I'm submitting it here because i think this version of
> clisp (2.25.1) is not supported anymore by it's authors.
> Does xindy still need this version, or can it be
> compiled using a newer one?

did you try switching to current version of clisp?
(and ideally, using OS-provided clisp, which Jörg made possible)

Best,
v.

(Continue reading)

Joachim Schrod | 12 Feb 2007 15:17
Picon
Favicon

Re: Request: New beta release

>>>>> "VV" == Vladimir Volovich <vvv <at> vsu.ru> writes:
VV> "JS" == Joachim Schrod writes:

JS> -- Compilation with gcc 4 does not work [bug ticket 1515980]
VV> [...]
JS> The first issue means that the rc3 tarball does not even compile
JS> on my own system; thus I really don't think that it's sensible to
JS> release it.

VV> it looks like a problem with compiling an outdated version of clisp
VV> (2.25.1) included into xindy, using GCC 4.0.

Yes.

VV> why is it a show-stopper for another xindy PRE-release?

Because I cannot do basic sanity tests before a release. Please note
that the README must also be updated, and adaption of the install
instructions must be done as well. But you're right in principle -- if
somebody could write a draft here; I would probably make a
pre-release.

VV> did you try switching to current version of clisp?

I had some problems with it, and did not yet investigate it further.
But this is probably the best way to handle the problem.

VV> (and ideally, using OS-provided clisp, which Jörg made possible)

This is a very interesting and very valuable option, but probably only
(Continue reading)


Gmane