Re: use native libintl/gettext?

Jonas Fonseca <[email protected]>
Newsgroups gmane.comp.web.links
Message-ID <[email protected]>
Hello Jeremy,

Jeremy C. Reed <[email protected]> wrote Thu, Dec 07, 2006:
> I am a long time elinks user. It is my browser of choice. Thank you for 
> your great work!

Thanks for your feedback. Always encouraging!

> Is there any way to have it use the system's native gettext libraries 
> instead of building and using the src/intl included with the source?

Not at the moment, and it is certainly not planned. Gettext has been
changed to integrate better with ELinks: it uses the ELinks memory
functions, has some specific wrappers etc.

There is a bugzilla entry which is currently marked WONTFIX. Pasky's
last remarks are:

	Our instance of libgettext is *heavily* customized and it is
	expected to get even more customized by the time, so using
	system gettext routines is not really feasible.

 - http://bugzilla.elinks.or.cz/show_bug.cgi?id=537

> Any patches to check for adequate gettext and use it if available?

I do not know of such patches.

> If not, would you be interested if used commonly-used autoconf to check 
> this?

Patches are always welcome, but I do not really see a reason. Is gettext
really that big?

> (I also found that the Makefile system used in buildling elinks is 
> different than I am used to when using autoconf configure.)

Yes, we changed to using a GNU make based build system instead of
automake, since ELinks has a lot of build-time options that caused
automake to generate huge makefiles because conditional are badly
implemented. Sad, but having a Makefile taking several megabytes of
storage is crazy.

-- 
Jonas Fonseca
_______________________________________________
elinks-dev mailing list
[email protected]
http://linuxfromscratch.org/mailman/listinfo/elinks-dev
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.