bug-gnu-libiconv
[Top][All Lists]
Advanced

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

Re: [bug-gnu-libiconv] trivial/cosmetic bugs for iconv 1.11


From: amores perros
Subject: Re: [bug-gnu-libiconv] trivial/cosmetic bugs for iconv 1.11
Date: Sat, 12 May 2007 19:12:32 +0000




From: Bruno Haible
....

Things like a version identification of the DLLs are
somewhat a luxury to me. You care more about it than I do. You are welcome
to investigate how to realize this and submit a patch - but please don't
expect me to implement this.

I took a look at this, but I think the auto-infrastructure may be over my head.

(I performed my work on a cygwin setup -- and against the gettext package,
because until now I forgot that this discussion started in relation to iconv.)

I pulled the latest gettext via anonymous cvs, and then made a "original" copy
of it, and ran sh autogen.sh -- presuming I need to autogen my cvs copy
before I try to configure and build it. (This was to achieve a baseline, before
I make a second pristine copy & try to put in rc handling.)

However, I seem to have failed with my process for my baseline.

I see this in my sh autogen.sh output:

== BEGIN QUOTE ==

Don't forget to
- add "gnulib-lib/Makefile" to AC_CONFIG_FILES in gettext-runtime/configure.ac
,
 - mention "gnulib-lib" in SUBDIRS in Makefile.am,
 - mention "-I gnulib-m4" in ACLOCAL_AMFLAGS in Makefile.am,
 - invoke gl_EARLY in gettext-runtime/configure.ac, right after AC_PROG_CC,
 - invoke gl_INIT in gettext-runtime/configure.ac.
1 out of 1 hunk FAILED -- saving rejects to file /tmp/glSO1312/vasprintf.rej
gnulib-tool: *** patch file gnulib-local/modules/vasprintf.diff didn't apply cle
anly
gnulib-tool: *** Stop.
1 out of 1 hunk FAILED -- saving rejects to file /tmp/glew2884/vasprintf.rej
gnulib-tool: *** patch file gnulib-local/modules/vasprintf.diff didn't apply cle
anly
gnulib-tool: *** Stop.
src/Makefile.am:38: compiling `envsubst.c' with per-target flags requires `AM_PR
OG_CC_C_O' in `configure.ac'

== END QUOTE ==

I don't seem to have either of the referenced tmp files - in fact, I don't
even have those subdirectories (/tmp/glSO1312 and /tmp/glew2884).

Unfortunately I'm not at all familiar with gnulib.

Frankly, it looks to me like the major portion of the work will be to
figure out how to work the auto-infrastructure and where to splice
in rc handling.

The actual script to update version numbers in an rc will be relatively
easy -- I have done something similar, except that my script to update
rc versions does them in place, and I think a different solution
would be more appropriate for gettext.

I looked at how the gettext man pages are handled:

gettext.x has the outline, and then help2man is used to generate
gettext.1.in, and then a simple sed call puts in the latest version into
a new file gettext.1. A dependency on root version.sh is used
to get the last bit rerun if the version is run.

I think an analogous setup with, e.g., gettext.rc.in being a version
independent file, and gettext.rc being the one with actual version
in it, would make sense.

The sed command isn't quite the same, because the VERSION variable
has the entire version, and it has to be split into numeric pieces for
an rc file, but that is pretty straightforward (and I already have written
bash3 script code to do that). The main question is
how and whether to handle non-numeric version numbers.

If a 0.16.3p4 version of gettext is released, that would have to be
converted to some numeric version in the rc file (e.g., 0, 16, 3, 4,
or maybe just 0,16,3 with a special build flag). This is because rc files
are restricted to purely numeric version numbers.

However, I am not sure whether it is worth the possibly substantial
amount of help I'd probably need to get through the auto-infrastructure
to get to the point where I can test putting in the relatively simple
part of converting, e.g., gettext.rc.in to gettext.rc.

_________________________________________________________________
PC Magazine’s 2007 editors’ choice for best Web mail—award-winning Windows Live Hotmail. http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507





reply via email to

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