Complete.Org: Mailing Lists: Archives: freeciv-dev: May 2001:
[Freeciv-Dev] Re: [patch] readline with -lcurses (PR#772)
Home

[Freeciv-Dev] Re: [patch] readline with -lcurses (PR#772)

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Gaute B Strokkenes <gs234@xxxxxxxxx>
Cc: freeciv-dev@xxxxxxxxxxx, bugs@xxxxxxxxxxxxxxxxxxx
Subject: [Freeciv-Dev] Re: [patch] readline with -lcurses (PR#772)
From: Thue <thue@xxxxxxx>
Date: Sat, 19 May 2001 13:44:55 +0200

On Saturday 19 May 2001 12:48, Gaute B Strokkenes wrote:
> On 19 May 2001, gs234@xxxxxxxxx wrote:
> > On Sat, 19 May 2001, thue@xxxxxxx wrote:
> >> On Saturday 19 May 2001 03:22, Greg Wooledge wrote:
> >>> If I copy those two files from a different project, ./configure
> >>> succeeds; but then make blows up:
> >>>
> >>> ranlib libcivserver.a gcc -DHAVE_CONFIG_H
> >>> -I. -I. -I.. -I./../common -I./../ai -I../intl -g -O2 -Wall -c
> >>> civserver.c make[2]: *** No rule to make target `@INTLDEPS@',
> >>> needed by `civserver'.  Stop.
> >>
> >> This is probably because debian unstable has gettext version
> >> 0.10.37-1, ie unrelated. Still would be nice to have it fixed :).
>
> I note that the civserver target in server/Makefile.am explicitly
> lists @INTLDEPS@ as a dependency.  I'm unsure as to why this is done,
> since the gettext manual (version 0.10.35, which is what I have access
> to) doesn't mention this being necessary in any of the pertinent
> sections.  Moreover, it seems to expand to the empty string under
> 0.10.35, so I wonder why it was added in the first place.

Looking at the code @INTLDEPS@ was exported in aclocal.m4. It seems that when 
running the aclocal in my distribution a newer version of the macros is used, 
which doesn't have/export it.

I tried just removing the 2 occurences of INTLDEPS and running gettextize, 
and it seems to work.
I suppose the changes this creates should be put into freeciv CVS?

Will this create problems for people with older versions of gettext? I guess 
they can just use the included gettext...

> In general, I think it might be a good idea to review the way we use
> gettext soon.  There seem to be a lot of strange add-ons and
> irregularities when compared to what the manual advises.

-Thue


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