[RFC] Future of "messages" targets

[Nicolas Goutte]

As we are moving away from using Makefile.am files, we have to convert the 
"messages" targets that are used by Scripty to extract user-visible messages 
into POT files.

I suggest that we use Bash scripts instead, and I suggest the name 
"makemessages.sh" for those scripts.

The biggest question is how to convert the dependency to rc.cpp, which is the 
same as calling explicitly:
$(EXTRACTRC) *.rc *.ui *.kcfg

I see two way for converting this and I am not sure about the best one:
- add the command explicitly in each makemessage.sh that needs it.
- let the code calling those scripts do the job when necessary.

Having every step explicitly written in the script makes that a developer 
knows all what is done but it also means that the developer should not forget 
to add the extra code (like for today, not to forget the rc.cpp dependency). 

Having the calling code handle it automatically could have advantages too, 
especially that a developer would not have to care about it. On the other 
side, nowadays there are many explicit calls of $EXTRACTRC for finding such 
files in sub-directories, so that a single call to $EXTRACTRC would be more 
useful and would avoid to process files twice (e.g. .ui .rc and .kcfg file in 
the same directory, as they are found again with a find(1) call).

Personally I would tend to prefer the first solution where the Bash script has 
everything and that there would not hidden $EXTRACTRC call.


Now a little discussion about why a Bash script.

Currently it is a Bash script embeded in a Makefile. However the calling code 
does not use any special feature of make, as the rc.cpp dependecy is checked 
by hand and not done by a "rc.cpp" target in a Makefile.

So converting the current code in the "messages" target to a separate Bash 
file should be easy, as the conversion can be done in an automatical way 
(removing the @ at start of lines, removing one $ in $$...)
(By the way: does somebody knows such a converting tool that would be 
ready-to-use?)

Having a separate Bash script means that the code can be edited with support 
from the editor (at least Kate has no Bash-support in the Makefile highlight 
mode).

Keeping the Bash syntax is also useful, as it means not changing too much the 
developers' habits, the (developers') I18N HOWTO and KDevelop (or eventual 
other KDE-code-generating tools). (I suppose that developers should be more 
concentrated on the conversion from automake/unsermake to scons/bksys than on 
how to convert the I18N extracting code.)

Using a Bash script is also useful in the transitional period, where KDE3 and 
KDE4 code will be side-by-side, especially in trunk/l10n. As the code for 
extracting is called from the admin directory, it is automatically dependent 
on the KDE version. (Also a smooth transition is possible for extragear or 
playground applications (if wanted by the respective developer) to use the 
new Bash script while keeping the old syntax of the "messages" target by just 
calling the script explicitly.)

Note that this is more a short-term change, kept in the current available 
context. However this change keeps open long-term evolutions. (That is also 
why I have chosen a file name with a ".sh" extension, so that in future, we 
can support another language when needed.)

(Of course the best long-term solution would be that a developer would only to 
tell the extraction system which sub-directories have to be processed and to 
which POT file it should be extracted (assuming that there are not any extra 
data files, otherwise a more code would be still needed.) This could be done 
from a Bash script too, for example with a call like:
$(EXTRACTION) myapp.pot `find . -type d`  
However this is not a short-term plan(or even middle-term), except if there 
are volunteers to implement it.)

Have a nice day!