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,
(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
(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
> 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
via global mechanism, so, imho, it's easier for maintainance (until we
get ordrules written in clisp) to simply have
script which is automatically invoked by:
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.
Registered Linux User | #278493
GPG Public Key | 8C44EDCD