xindy - A Flexible Indexing System

On Wed, Jun 08, 2005 at 10:25:53PM +0200, Gour wrote:
> Dear Xindy users,
> The current snapshot is at:
> 
> http://dev.atmarama.org/repos/xindy/xindy-2.3-alpha1.tar.gz (8MB)
> 
> and tarball contains the complete source-structure, but, as I wrote
> above, only rte & binaries (src) directories are built.
> 
> If someone has some time for testing, pls. let me know if you
> experience some problem, while I'll continue with the rest, i.e.
> putting the remaining modules (doc, make-rules, modules &
> user-commands) in the build process.
> 

Fine, thanks 

It is failing here on

config.status: error: cannot find input file: modules/Makefile.in
make: *** [config.status] Error 1

See attached log if something there is of help

Cheers

-- 
Agustin

Agustin Martin (agustin.martin@...) wrote:

> Fine, thanks 
> 
> It is failing here on
> 
> config.status: error: cannot find input file: modules/Makefile.in
> make: *** [config.status] Error 1

Ahh...alpha diseases :-(

make dist is not (yet) workable and somehow one extra line ended up in
the root's configure.ac.

Change the invoking of macro:

AC_CONFIG_FILES([Makefile \
                binaries/Makefile \
                tex2xindy/Makefile \
                modules/Makefile \
])

to:

AC_CONFIG_FILES([Makefile \
                binaries/Makefile \
                tex2xindy/Makefile \
])

Hope it solves the problem.

Sincerely,
Gour

p.s. I believe there will be some time during the week-end to include
the remaining modules and get alpha2 ;)

-- 
Registered Linux User	| #278493
GPG Public Key		| 8C44EDCD

On Fri, Jun 10, 2005 at 06:31:35PM +0200, Gour wrote:
> Agustin Martin (agustin.martin@...) wrote:

> > config.status: error: cannot find input file: modules/Makefile.in
> > make: *** [config.status] Error 1
>=20
> Change the invoking of macro:
>=20
> AC_CONFIG_FILES([Makefile \
>                 binaries/Makefile \
>                 tex2xindy/Makefile \
>                 modules/Makefile \
> ])
>=20
> to:
>=20
> AC_CONFIG_FILES([Makefile \
>                 binaries/Makefile \
>                 tex2xindy/Makefile \
> ])
>

Working after rebuilding configure. Now the problem is that it tries to
install directly in /usr/lib/xindy, not using $(DESTDIR),

cp xindy.run xindy.mem /usr/lib/xindy
cp: Cannot create =AB/usr/lib/xindy/xindy.run=BB: ...

Something like this patch might help,

--------------------------------------------------------------
--- xindy-2.3-alpha1.orig/binaries/Makefile.am
+++ xindy-2.3-alpha1/binaries/Makefile.am
@@ -13,7 +13,7 @@
 MODULEDIR =3D $(pkgdatadir)/modules
=20
 # Where the files xindy.run and xindy.mem should be installed.
-INSTLIBDIR =3D $(pkglibdir)
+INSTLIBDIR =3D $(DESTDIR)$(pkglibdir)
=20
 # Target section
-------------------------------------------------------------=20

It is still hard for me to assume that the only way to have the
missing clisp plugins is having in the source all clisp and build
it, and that there are no other tricks for that. But since I am
completely unfamiliar with clisp (just have some minimal emacs
lisp knowledge) I cannot add nothing about that.

Cheers,

--=20
Agustin

Agustin Martin (agustin.martin@...) wrote:

Hi!

> Working after rebuilding configure. Now the problem is that it tries to
> install directly in /usr/lib/xindy, not using $(DESTDIR),
> 
> cp xindy.run xindy.mem /usr/lib/xindy
> cp: Cannot create «/usr/lib/xindy/xindy.run»: ...
> 
> Something like this patch might help,

Thanks. You see, it's pretty raw :-(

> It is still hard for me to assume that the only way to have the
> missing clisp plugins is having in the source all clisp and build
> it, and that there are no other tricks for that. But since I am
> completely unfamiliar with clisp (just have some minimal emacs
> lisp knowledge) I cannot add nothing about that.

I also cannot say much..

However, I try to understand xindy runtime-engine & clisp-plugins in the
light of e.g. extending some scripting language - e.g. Ruby - so in
order to do that, you have to re-compile the whole language interpreter
to be able to use the new functionality.

Similarly, clisp has to be built with 'extended' features (aka plugins)
in order that xindy (program) can use it.

Probably, separating runtime engine from the kernel was a logical choice
in the time when xindy was conceived.

Reflecting on this issue today, it would (maybe) make more sense to
have everything in the kernel, or (maybe) even better, to have xindy
(re)-written in some more popular programming language.

otoh, xindy helped me when I was working on one book, and all I want is
to make build-process easier so that we can see xindy included in the
main Linux-distros.

Sincerely,
Gour

p.s. Unfortunately, I'm still seized by other duties so I have to wait a
few days more before resuming work on the xindy-distribution.

-- 
Registered Linux User	| #278493
GPG Public Key		| 8C44EDCD

Agustin Martin (agustin.martin@...) wrote:

> Working after rebuilding configure. Now the problem is that it tries to
> install directly in /usr/lib/xindy, not using $(DESTDIR),

Actually, I think it's alright. It installs into:

/prefix/lib/xindy

so you can chooses destination via --prefix=dir parameter.

Or am I missing something?

Sincerely,
Gour

-- 
Registered Linux User	| #278493
GPG Public Key		| 8C44EDCD

>>>>> "AM" == Agustin Martin <agustin.martin@...> writes:

AM> It is still hard for me to assume that the only way to have the
AM> missing clisp plugins is having in the source all clisp and build
AM> it, and that there are no other tricks for that.

You are right that this is not the only way. It is possible to compile
plugins outside the CLISP tree and use them. One `just' needs to have
a CLISP installation with the specific features needed by xindy.

But this opportunity existed already for the last few years, and
nobody except Christian Gundlach used it. Instead, popular demand was
for a "configure ; make ; make install" type distribution -- and to
achieve that with reasonable effort, I added the CLISP source to the
distribution.

With an external CLISP, the precondition for the xindy source
distribution would be:
 -- A CLISP installation with plugin support (called `external
    modules' in the CLISP world),
 -- the regex plugin from the CLISP distribution,
 -- and the CLISP utilities to create memory images from module sets.
If one of these preconditions is not met, the user must download CLISP
source and must make it first. The configure script would have to
check for all these preconditions. (Btw, the CLISP utilities are often
not located in $PATH, but in some lib directory.) One also has to
learn how the CLISP linkkit feature works -- this is used
automatically for all in-tree modules.

Adding the CLISP source to the distribution got me
 -- an easy way to add my plugin (just one symlink and one additional
    option for CLISP's configure).
 -- no need to create a complex configure check where I didn't even
    know how to check for the CLISP features named above
 -- no need to test portable out-of-tree plugin creation
 -- the assurance that I get a CLISP version that is working with my
    plugin, since I have tested it. With user-supplied CLISP versions,
    I would not be as sure.

It cost me a few MB increase in download size. This price was easy to
pay for the advantages above.

Cheers,
	Joachim

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod					Email: jschrod@...
Roedermark, Germany

	``How do we persuade new users that spreading fonts across the page
	like peanut butter across hot toast is not necessarily the route to
	typographic excellence?''			-- Peter Flynn

>>>>> "G" == Gour  <list@...> writes:

G> Probably, separating runtime engine from the kernel was a logical
G> choice in the time when xindy was conceived.

The separation has been done by me just four weeks ago, so I still
consider it a logical choice. I did it purely for organizational
reasons: the rte doesn't change and is very stable, whereas the kernel
is supposed to change in the future.

G> Reflecting on this issue today, it would (maybe) make more sense to
G> have everything in the kernel, or (maybe) even better, to have xindy
G> (re)-written in some more popular programming language.

This has been discussed in the past already. For reference, a summary
of these discussions.

I welcome everybody who wants to reimplement xindy in some other
language, and I will provide access to the xindy infrastructure. E.g.,
sub-projects in CVS, a part of the Web site, etc. I will not
participate in such a re-implementation effort, though.

*If* I will ever work on the rte level again, it will be to
re-implement the CLISP plugin ordrules in Common Lisp. This would get
rid of the whole rte topic. I could use a standard CLISP afterwards,
readily available in many environments.

Cheers,
	Joachim

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod					Email: jschrod@...
Roedermark, Germany

	``How do we persuade new users that spreading fonts across the page
	like peanut butter across hot toast is not necessarily the route to
	typographic excellence?''			-- Peter Flynn

Joachim Schrod (jschrod@...) wrote:

> You are right that this is not the only way. It is possible to compile
> plugins outside the CLISP tree and use them. One `just' needs to have
> a CLISP installation with the specific features needed by xindy.

'just' :-)

> But this opportunity existed already for the last few years, and
> nobody except Christian Gundlach used it. Instead, popular demand was
> for a "configure ; make ; make install" type distribution -- and to
> achieve that with reasonable effort, I added the CLISP source to the
> distribution.

That's a smart step.

> It cost me a few MB increase in download size. This price was easy to
> pay for the advantages above.

Sure. As soon as I get some reasonably big free-time slot, I'll resume
work on source-distribution. The remaining parts should be easier to
accomplish and then...polishing.

Sincerely,
Gour

-- 
Registered Linux User	| #278493
GPG Public Key		| 8C44EDCD

Joachim Schrod (jschrod@...) wrote:

> G> Probably, separating runtime engine from the kernel was a logical
> G> choice in the time when xindy was conceived.
> 
> The separation has been done by me just four weeks ago, so I still
> consider it a logical choice. I did it purely for organizational
> reasons: the rte doesn't change and is very stable, whereas the kernel
> is supposed to change in the future.

I did not express myself clearly, i.e. I didn't think about separate
distributions, but about the fact there xindy build consists of runtime
& kernel parts.

> I welcome everybody who wants to reimplement xindy in some other
> language, and I will provide access to the xindy infrastructure. E.g.,
> sub-projects in CVS, a part of the Web site, etc. I will not
> participate in such a re-implementation effort, though.

At the moment I'm in the process of learning Haskell and consider it is
nice to have some general application written in FP language.

otoh, I tend to be practical, so it is better to wrap my head against
some simple rules in order to write xindy styles instead of
re-inventing the wheel :-)

In other words, by providing configure & make distribution I'll be
happy.

> *If* I will ever work on the rte level again, it will be to
> re-implement the CLISP plugin ordrules in Common Lisp. This would get
> rid of the whole rte topic. I could use a standard CLISP afterwards,
> readily available in many environments.

This *would* be great (in terms of functionality & cosmetic) !

Sincerely,
Gour

-- 
Registered Linux User	| #278493
GPG Public Key		| 8C44EDCD

>>>>> "G" == Gour  <list@...> writes:

G> p.s. I believe there will be some time during the week-end to include
G> the remaining modules and get alpha2 ;)

Before you do so, please get the new components from the SF download
site: xindy-rte-2.2.tar.gz and xindy-kernel-2.2-rc2-pre4.tar.gz

Changes:

 -- Internal version identification for components has been moved to
    lisp files, no internal VERSION files any more.

    There is still one VERSION file in the overall distribution,
    though. This files holds the xindy distribution release number,
    and is read at run time by xindy.pl.

 -- No platform directory and no PLATFORM file any more, in kernel
    sources. Instead it uses binaries/ too, which should ease your
    integration work.

    Platform description has been reduced to cpu type and operating
    system, and is determined at compile time of the CLISP plugin.
    (autoconf has been used for that. Boy, the documentation for that
    software is worse than xindy's, unbelievable.)

 -- Some cleanup of the rte/ordrules directory.
 -- Minor bug fixes in tex2xindy.

Changed files:
 -- rte: ordrules/*
 -- kernel: src/*, tex2xindy/tex2xindy.l, binaries/*

I consider the rte component finished for this release.

Cheers,
	Joachim

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod					Email: jschrod@...
Roedermark, Germany

	``How do we persuade new users that spreading fonts across the page
	like peanut butter across hot toast is not necessarily the route to
	typographic excellence?''			-- Peter Flynn

Joachim Schrod (jschrod@...) wrote:

> Before you do so, please get the new components from the SF download
> site: xindy-rte-2.2.tar.gz and xindy-kernel-2.2-rc2-pre4.tar.gz

Oh..surprise :-)

> Changes:
> 
>  -- Internal version identification for components has been moved to
>     lisp files, no internal VERSION files any more.

At the moment, I was using $PACKAGE_VERSION as replacement for VERSION
file.

>     There is still one VERSION file in the overall distribution,
>     though. This files holds the xindy distribution release number,
>     and is read at run time by xindy.pl.

OK. When I download new files, Ill discover what it holds.

>  -- No platform directory and no PLATFORM file any more, in kernel
>     sources. Instead it uses binaries/ too, which should ease your
>     integration work.

alpha1 tarball does not use PLATFORM, not platform directory, but uses
$(build_triplet) variable.

>     Platform description has been reduced to cpu type and operating
>     system, and is determined at compile time of the CLISP plugin.
>     (autoconf has been used for that. Boy, the documentation for that
>     software is worse than xindy's, unbelievable.)

I use $(build_triplet) from the top-level configure.ac

>  (autoconf has been used for that. Boy, the documentation for that
>  software is worse than xindy's, unbelievable.)

True. It's unbelievable taking into consideration how many packages,
i.e. users use this tools :-o

>  -- Some cleanup of the rte/ordrules directory.
>  -- Minor bug fixes in tex2xindy.
> 
> Changed files:
>  -- rte: ordrules/*
>  -- kernel: src/*, tex2xindy/tex2xindy.l, binaries/*
> 
> I consider the rte component finished for this release.

Great!

In a few days I hope to resume my work and have complete distro ready
for testing.

Sincerely,
Gour


-- 
Registered Linux User	| #278493
GPG Public Key		| 8C44EDCD

>>>>> "G" == Gour  <list@...> writes:

>> -- No platform directory and no PLATFORM file any more, in kernel
>> sources. Instead it uses binaries/ too, which should ease your
>> integration work.

G> alpha1 tarball does not use PLATFORM, not platform directory, but uses
G> $(build_triplet) variable.

>> Platform description has been reduced to cpu type and operating
>> system, and is determined at compile time of the CLISP plugin.
>> (autoconf has been used for that. Boy, the documentation for that
>> software is worse than xindy's, unbelievable.)

G> I use $(build_triplet) from the top-level configure.ac

Yes, but you need to change this in your code; that's why I wrote
about it. Up to now, version and platform identifier was included into
defaults.xdy, during compilation of the xindy source. This isn't the
case any more.

The platform identification has been moved to the run time
environment, where I have introduced ordrules/version.lisp.in. There,
the platform value gets inserted during configure. ordrules/configure
was there anyhow, it is needed by CLISP, I adapted it. Please note
that you should not call that configure during global configure;
that's done by make in clisp. I.e., no recursing into
ordrules/configure by the top-level one.

NB: How did you get $(build_triplet)? I have autoconf 2.59 and
automake 1.9.1 installed, and it didn't know about that variable. 
AC_CANONICAL_HOST delivers host, host_cpu, host_vendor, and host_os. 
As vendor is not relevant for xindy, I chose to use
"@host_cpu@...@" as platform identification.

	Joachim

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod					Email: jschrod@...
Roedermark, Germany

	``How do we persuade new users that spreading fonts across the page
	like peanut butter across hot toast is not necessarily the route to
	typographic excellence?''			-- Peter Flynn

Joachim Schrod (jschrod@...) wrote:

> The platform identification has been moved to the run time
> environment, where I have introduced ordrules/version.lisp.in. There,
> the platform value gets inserted during configure. ordrules/configure
> was there anyhow, it is needed by CLISP, I adapted it. Please note
> that you should not call that configure during global configure;
> that's done by make in clisp. I.e., no recursing into
> ordrules/configure by the top-level one.

Well, during global configure, I call rte/configure (I removed argument
checking 'cause global configure pass its parameters) which invokes the
rest in the chain.

I still think we could simplify everything by simply using 'version'
from the 'sumo-tarball', i.e. 'PACKAGE_VERSION'.

If you plan to have 'source-distribution' as a whole, and you say that
runtime is pretty stable, then why fiddling with several 'versions' ?

All the components can co-exist under revision control system, and we
can easily combine them together, i.e. it is easy to simply tag some
status in rcs as e.g. 'xindy-2.4' and this includes different versions
of the individual components, and xindy -V can denote version of the
package, i.e. '2.4'.

Of course, this makes sense if you plan to have only one
source-distribution.

You mentioned (in some previous) email, problem with non-Linux OS-es
(AIX, HP-UX), but I believe autoconf works there?

otoh, what is the difference of identifying platform by topmost-level
configure or via clisp?

> NB: How did you get $(build_triplet)? I have autoconf 2.59 and
> automake 1.9.1 installed, and it didn't know about that variable. 

Don't know. It simply exists :-)

I have 2.59 & 1.9.5.


When I get into finishing this source-distribution (I hope you do not
plan any further changes soon), I'll take a look.

Sincerely,
Gour

-- 
Registered Linux User	| #278493
GPG Public Key		| 8C44EDCD

>>>>> "G" == Gour  <list@...> writes:

G> When I get into finishing this source-distribution (I hope you do not
G> plan any further changes soon)

No further changes to rte are planned in the next few months. I.e.,
not this year.

Changes to the kernel Lisp code are not probable in the next few
weeks to months.

Changes to auxiliary code in the kernel archive are probable, though
-- e.g., to tex2xindy, should my questions from yesterday be answered
on this list. Also, the wrapper scripts will be updated ASAP.
Changes to the modules will happen quite soon, too.

Cheers,
	Joachim

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod					Email: jschrod@...
Roedermark, Germany

	``How do we persuade new users that spreading fonts across the page
	like peanut butter across hot toast is not necessarily the route to
	typographic excellence?''			-- Peter Flynn

Joachim Schrod (jschrod@...) wrote:

Hi!

I've some free-time and would like to resume working on xindy source
distribution...

> G> I use $(build_triplet) from the top-level configure.ac

> The platform identification has been moved to the run time
> environment, where I have introduced ordrules/version.lisp.in. 


I removed the old rte sources and cannot diff with the latest version,
so can you tell me where is version.lisp file used?

Sincerely,
Gour

-- 
Registered Linux User	| #278493
GPG Public Key		| 8C44EDCD

>>>>> "G" == Gour  <list@...> writes:
G> Joachim Schrod (jschrod@...) wrote:

G> I've some free-time and would like to resume working on xindy source
G> distribution...

G> I use $(build_triplet) from the top-level configure.ac

>> The platform identification has been moved to the run time
>> environment, where I have introduced ordrules/version.lisp.in. 

G> I removed the old rte sources and cannot diff with the latest version,
G> so can you tell me where is version.lisp file used?

Short version:

That all happens during make in clisp-2.33.2.
There, version.lisp is created from version.lisp.in, and also loaded
during creation of lispinit.mem, which we will call base.mem later in
the xindy production process.

For your source distribution work, you can just throw out any handling
of $(build_triplet), and use the current ordrules/ directory instead.


Longer explanation:

During configure, ordrules is symlinked to clisp-*/modules/. Thus, it
gets a CLISP plug-in that we can use. Usage is prepared by passing the
option --with-module=ordrules to clisp's configure and to clisp's
makemake.

During make in clisp*, all plug-ins are copied from modules/ to src/,
and the selected plug-ins are compiled. For that, in each module
directory configure and make are called. Eventually, all selected
plug-ins are loaded to create lisp.run and lispinit.mem; for that a
file load.sh is used that exists in each modules directory. This files
specifies the object files that shall be bound to lisp.run and the
lisp files that shall be loaded for lispinit.mem. (A plug-in consists
of C parts that are compiled into object files, and of Lisp parts.)

For the rte-2.2 archive, I changed ordrules/ configure, Makefile.in,
and load.sh files. ordrulesi.lisp was renamed to ordrulesi.lsp, as it
is named in the CVS tree. Furthermore, I added
ordrules/version.lisp.in. This is all used fully automatically during
make by the CLISP plug-in compilation system, and is not of concern
for actions that happen outside.

At the same time, I made the Lisp code a bit cleaner and introduced a
new namespace. The kernel code has been changed to use that internal
namespace. It has also be changed to not embody any platform or
version number in defaults.xdy any more. This is all internal Lisp
stuff now, and not handled by configure or make any more.

In fact, your emails triggered me to make that change. I realized that
all these different VERSION files confuse people and that there is
only one version that counts for final distribution; the xindy release
number. All other identifiers are for my own internal code and
component management; configure and make have nothing to do with them.

Cheers,
	Joachim

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod					Email: jschrod@...
Roedermark, Germany

	``How do we persuade new users that spreading fonts across the page
	like peanut butter across hot toast is not necessarily the route to
	typographic excellence?''			-- Peter Flynn

Joachim Schrod (jschrod@...) wrote:

> G> I use $(build_triplet) from the top-level configure.ac
> 
> Yes, but you need to change this in your code; that's why I wrote
> about it. Up to now, version and platform identifier was included into
> defaults.xdy, during compilation of the xindy source. This isn't the
> case any more.

It looks that things are a little bit more clear to me...

After running 'xindy -V' from the binary distribution, I get:

xindy release: 2.2-rc2	 (a)
xindy script version: 1.06	(b)
xindy core version: 2.2-rc2-pre2	(c)
xindy run time engine: ix86-linux-glibc22, version 2.2-rc2	(d)
CLISP version 2.33.2 (2004-06-02) (built on pussy.r.npc.de [192.168.129.7])
    architecture: X86_64	(e)

Pls. correct me if I'm wrong, but I think this should be simplified,
i.e.:

(a) can be retrieved from a global PACKAGE_VERSION variable available
after running top-level configure

(b) is not so important, i.e. if we have the complete source
distribution under revision control system and release is tagged, then
it is very simple to 'discover' what is the 'script version'.

(c) 'core-version' can be also known as (b)

(d) by distributing complete xindy-sources as a package, 'core-version'
is known in the same way as (b). Moreover, 'ix86-linux-glibc22' part is
obsolete now.

(e) version of CLISP is also known as (b), while the arch (if needed
for debugging purposes) can be easily known as e.g. 'uname -a'.

All in all, I vote for simplifying the present version-number scheme
considering that is it enough to track a package number of the
distribution - I do not use the need for this info for end-users -
while for the debugging purposes all the other version-numbers can be
deduced from the revision control system. (Of course, this would
require to re-structure the modules in CVS to represent the
xindy-source hierarchy.)


> The platform identification has been moved to the run time
> environment, where I have introduced ordrules/version.lisp.in. There,
> the platform value gets inserted during configure. ordrules/configure
> was there anyhow, it is needed by CLISP, I adapted it. Please note
> that you should not call that configure during global configure;
> that's done by make in clisp. I.e., no recursing into
> ordrules/configure by the top-level one.

I do not use the use of ordrules/version.lisp.in. 

Besides that, the new ordrules/configure.ac complicates things, i.e. it
does not help to have ordrules/configure.ac since this part is not under
automake 'cause top-level configure simply calls rte/configure script
which does the job. In other words we do not create

rte/ordrules/Makefile 

via global mechanism, so, imho, it's easier for maintainance (until we
get ordrules written in clisp) to simply have 

rte/ordrules/configure

script which is automatically invoked by:

ordrules/configure.

Until I got reply from you, I'll continue with the rest of the package
using old version.


After finishing it will be simple to add/modify these 'version-numbers'
& 'configure' issues.


Sincerely,
Gour

-- 
Registered Linux User	| #278493 
GPG Public Key		| 8C44EDCD

Joachim Schrod (jschrod@...) wrote:

Thank you for prompt reply.

> Short version:
> 
> That all happens during make in clisp-2.33.2.
> There, version.lisp is created from version.lisp.in, and also loaded
> during creation of lispinit.mem, which we will call base.mem later in
> the xindy production process.

OK.

> 
> For your source distribution work, you can just throw out any handling
> of $(build_triplet), and use the current ordrules/ directory instead.

See my other post regarding 'ordrules/configure.ac'.

> Longer explanation:
> 
> During configure, ordrules is symlinked to clisp-*/modules/. Thus, it
> gets a CLISP plug-in that we can use. Usage is prepared by passing the
> option --with-module=ordrules to clisp's configure and to clisp's
> makemake.

That's clear.

> During make in clisp*, all plug-ins are copied from modules/ to src/,
> and the selected plug-ins are compiled. For that, in each module
> directory configure and make are called. Eventually, all selected
> plug-ins are loaded to create lisp.run and lispinit.mem; for that a
> file load.sh is used that exists in each modules directory. 

You mean 'link.sh' ?

> This files specifies the object files that shall be bound to lisp.run
> and the lisp files that shall be loaded for lispinit.mem. (A plug-in
> consists of C parts that are compiled into object files, and of Lisp
> parts.)

Here it would be nice to replace those xindy-modules with clisp
sources ;)

> For the rte-2.2 archive, I changed ordrules/ configure, Makefile.in,
> and load.sh files. ordrulesi.lisp was renamed to ordrulesi.lsp, as it
> is named in the CVS tree. Furthermore, I added
> ordrules/version.lisp.in. This is all used fully automatically during
> make by the CLISP plug-in compilation system, and is not of concern
> for actions that happen outside.

That's nice. One concern: should we distribute ordrules/configure
created from configure.ac, or it is possible to just use old
ordrules/configure (reasons in my other post).

> At the same time, I made the Lisp code a bit cleaner and introduced a
> new namespace. The kernel code has been changed to use that internal
> namespace. It has also be changed to not embody any platform or
> version number in defaults.xdy any more. This is all internal Lisp
> stuff now, and not handled by configure or make any more.

Great!

> In fact, your emails triggered me to make that change. I realized that
> all these different VERSION files confuse people and that there is
> only one version that counts for final distribution; the xindy release
> number. 

Wonderful!

> All other identifiers are for my own internal code and component
> management; configure and make have nothing to do with them.

Clear. The only remaining issue: should we in ordrules use configure.ac
mechanism - distribute generated  configure script -  or use  old configure 
script?

Sincerely,
Gour

-- 
Registered Linux User	| #278493
GPG Public Key		| 8C44EDCD

>>>>> "G" == Gour  <list@...> writes:

>> The platform identification has been moved to the run time
>> environment, where I have introduced ordrules/version.lisp.in. There,
>> the platform value gets inserted during configure. ordrules/configure
>> was there anyhow, it is needed by CLISP, I adapted it. Please note
>> that you should not call that configure during global configure;
>> that's done by make in clisp. I.e., no recursing into
>> ordrules/configure by the top-level one.

G> I do not use the use of ordrules/version.lisp.in. 

G> Besides that, the new ordrules/configure.ac complicates things, i.e. it
G> does not help to have ordrules/configure.ac since this part is not under
G> automake 'cause top-level configure simply calls rte/configure script
G> which does the job. In other words we do not create
G> rte/ordrules/Makefile 
G> via global mechanism, 

You seem to think it's more complicated than it actually is.

You MUST NOT call ordrules/configure.
You MUST NOT create neither version.lisp nor Makefile in ordrules/.
You SHOULD NOT create ordrules/configure from configure.ac, at least
not without good reasons (i.e., when the supplied configure doesn't
work).

ordrules/configure and ordrules/*.in are not part of xindy
configuration, they are part of the CLISP plug-in build system. Please
don't change them.

configure.ac is not new. There was always a configure.in in ordrules,
and there was always a generated configure script in ordrules. Nothing
has changed here, except renamed configure.in to configure.ac as it is
proper naming convention now.

All you need to do is

 1) Take ordrules/* from the new rte archive and replace in your
    distribution the old ordrules/* files. No need to change any
    configuration or any Makefile at all.

 2) Take src/* from kernel. Replace the previous kernel files.

 3) You might have configuration clauses to create default.xdy that
    reference $(build_triplet) or some version number. Throw them out,
    you don't need them any more. If you don't have such a
    configuration, don't care.

 4) The Makefile in kernel has been changed by me, another lisp file
    has been added, and the creation of defaults.xdy has been
    changed. These changes must be moved to your sources, too.


Cheers,
	Joachim

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod					Email: jschrod@...
Roedermark, Germany

	``How do we persuade new users that spreading fonts across the page
	like peanut butter across hot toast is not necessarily the route to
	typographic excellence?''			-- Peter Flynn

>>>>> "G" == Gour  <list@...> writes:

G> One concern: should we distribute ordrules/configure created from
G> configure.ac, or it is possible to just use old ordrules/configure
G> (reasons in my other post).

You should use the new configure from the rte archive. Don't create
it, just use it. Just replace everything in ordrules/* and you're
done. Please don't try to integrate ordrules/configure.ac in your
autoconf/automake setup, that won't work.

If it makes your life easier, you can remove ordrules/configure.ac
from the distribution, it's not needed at all by you.

And no, you can not use the old ordrules/configure any more. It tries
to create files that aren't there any more, and doesn't create files
that are needed. CLISP creation will abort with errors.

Cheers,
	Joachim

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod					Email: jschrod@...
Roedermark, Germany

	``How do we persuade new users that spreading fonts across the page
	like peanut butter across hot toast is not necessarily the route to
	typographic excellence?''			-- Peter Flynn

Joachim Schrod (jschrod@...) wrote:

> You should use the new configure from the rte archive. Don't create
> it, just use it. Just replace everything in ordrules/* and you're
> done. Please don't try to integrate ordrules/configure.ac in your
> autoconf/automake setup, that won't work.

OK. Clear.

> If it makes your life easier, you can remove ordrules/configure.ac
> from the distribution, it's not needed at all by you.

No need.

> And no, you can not use the old ordrules/configure any more. It tries
> to create files that aren't there any more, and doesn't create files
> that are needed. CLISP creation will abort with errors.

Thank you.

I imported new sources and now I can resume my work :-)

p.s. When I finish the whole distribution, I'll put it online so you
can easily rsync the whole package (I use darcs instead of CVS), but
I'll also provide tarball.

Sincerely,
Gour

Registered Linux User	| #278493
GPG Public Key		| 8C44EDCD

Joachim Schrod (jschrod@...) wrote:

> NB: How did you get $(build_triplet)? I have autoconf 2.59 and
> automake 1.9.1 installed, and it didn't know about that variable. 
> AC_CANONICAL_HOST delivers host, host_cpu, host_vendor, and host_os. 
> As vendor is not relevant for xindy, I chose to use
> "@host_cpu@...@" as platform identification.

True. $(build_triplet) works in Makefiles, while for other, we can use
'host' or 'build' which are like aliases for 'host_triplet' &
'build_triplet'.

The 'advantage' is that they come as free, i.e. no need for AC_SUBST.

Sincerely,
Gour

-- 
Registered Linux User	| #278493
GPG Public Key		| 8C44EDCD