[RFC] Second take for "messages" targets

[Nicolas Goutte]

From the experience of the first thread "[RFC] Future of "messages" targets",
it seems that it is more wanted something without using Bash at all for the 
simplier cases and also it seems that a furture change that what I had 
planned is wanted.

So I am proposing another idea, which at first can be sourced by Bash, and 
then (much?) later can be parsed by Perl's (or Python's?) regular expressions 
(or any other better mean that somebody can think of).

The main advantage of the solution is that it would be simplier for 
application developers.

The idea is to define a file (what name? "scripty.txt"? "message.scripty"?) 
for each needed POT file. The file will have keys of the type:
key=value


For simple applications, where all files are in a same directory, the file 
would be as simple as

DIRECTORIES=.
POTFILE=myapp.pot

Scripty would process that file and automatically extract the C++ files and 
the possibly present *.ui *.rc and *.kcfg files.

Note: POTFILE is always only a simple filename without any path.

For applications, where a POT file needs to be extracted from more 
directories, the file would be:

DIRECTORIES=AUTO
POTFILE=myapp.pot

For applications wanting to control which directories:
DIRECTORIES=. dir1 dir2 dir3 dir4...
POTFILE=myapp.pot


(If not any shell is wanted, we cannot use find(1) at all, so all directories 
would to be explicitly declared. Of course, we could perhaps use ` as escape 
character to still use find, but that would mean to use Bash again.)


For applications, having other data to be extracted, we cannot keep such a 
simple structure, so we need external scripts:

DIRECTORIES=AUTO
POTFILE=myapp.pot
SCRIPT=myextraction.sh
SCRIPTRESULT=rc.cpp

Note: the script (in Bash, in Perl 5.6  or in Python 2.1) needs an extension 
to know what language it is. (Scripty traditionally forces the interpreter to 
be called explicitly and does not let #! do the job alone.)

Note2: the SCRIPTRESULT would be needed to be able to remove that file.


Currently when extra data has to be extracted, it is done indirectly by using 
a C++ file, mostly rc.cpp. However this has the drawback, not to be able
to add correct comments for thet translators (especially original file names 
and original line numbers, especially when there are multiple places.)
So the best would be to allow generating extra POT files directly and that 
Scripty cares about merging those files into the POTFILE.

So we could have:

DIRECTORIES=AUTO
POTFILE=myapp.pot
SCRIPT=myextraction.sh
EXTRAPOT=myextraction.pot

The files defined by EXTRAPOT will be put in the file defined POTFILE (by 
using Gettext's msguniq(1) ).


The big drawback of this solution is that automatical conversion from today's 
"messages" target will be more difficult, if not impossible. A possible 
intermediate step is to have a

FORCESCRIPT=message.sh

with a message.sh script containing the current "messages" target code (going 
back to my first proposal, but this time only as a temporary solution).

We would probably also need a FORCEPOTFILE (replacing POTFILE)
for playing with cross-module naming of the POT file, like done in kdebase for 
defining a POT file in kdelibs' POT directory.

Have a nice day!