savannah-hackers-public
[Top][All Lists]
Advanced

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

[Savannah-hackers-public] Porting savane from PHP to Perl on version 3.1


From: socketpro
Subject: [Savannah-hackers-public] Porting savane from PHP to Perl on version 3.1-cleanup
Date: Sat, 13 Sep 2014 20:07:13 -0400

UPDATE: I'm working on porting savane's po/ directory to use GNU Autotools' 
conventions.

PHP (and thus savane) does not care about how the .mo files are generated, just 
that they are available on the system for use in $(localedir). Most other 
internationalized applications work like this also, unless you tell them to not 
be NLS aware. So the build system has much freedom in deciding how to place the 
i18n and l10n files onto the system. (There is a whole entire directory tree 
under /usr/local/share/locale dedicated to I18N and L10N).

gettext with GNU Autotools here does not provide any obvious advantages when 
using languages other than C/C++ when in reference to the building and 
installing aspects. This is in very sharp contrast to c/c++/java/c#, etc 
languages.

So it would not hurt at all to dis-use any "GETTEXT" related macros in 
aclocal.m4. Going to use configure.ac somehow to make gettext handling 
consistent package wide to eliminate spaghettin handling of gettext related 
stuff. Spaghetti is of the devils.

The sphagetti code imported from the call to gettextize dumps tons of c/c++ 
stuff in the srcdir, including forcing use of LIBTOOL macros. Little benefits 
are seen, and then developer has to put the puzzle where the "C centric" system 
has to go in the package.

I think what the developer did was mostly correct.

He added custom code in po/Makefile.am to do the install of the .mo files. This 
Makefile.am code does all of savane's gettext handling: generating files, 
updating .po files with new code refs (usually done after edited code), 
installing (looks scary), uninstalling (looks scary also), and there are some 
code blocks in there to generate different types of reports for developer 
purposes.

I'll use the old devs route: extended Makefile.am code to drive raw gettext 
suite tools. I'll port some of his/her codes to use autoconfiscated variables 
like MKDIR_P and ECHO etc rather than hand written, custom purposed, or guessed 
stuff. And I'll rig all of this extension code so that it obeys configure.ac 
and $(top_srcdir)/Makefile.am files, because currently it does not do that. 

The recommendations in the Autoconf and Automake manuals are a starting guide.



reply via email to

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