[RFC] Future of "messages" targets

Nicolas Goutte nicolasg at snafu.de
Tue Sep 13 11:49:45 BST 2005


On Tuesday 13 September 2005 11:36, Stephan Kulow wrote:
> Am Dienstag, 13. September 2005 11:25 schrieb Nicolas Goutte:
> > 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.
>
> I think we should provide shell functions that can be used from apps shell
> scripts. So the calling code doesn't call the bash script but sources it
> with the variables and the functions set. So you wouldn't do
> "./k3b/messages.sh" but "admin/create-messages.sh k3b" - this way you avoid
> too much of code duplication and still have a) the developer aware of what
> is going on as he has to add a default_extractrc call in his shell script
> and b) have a way to do a check if the default_extractrc is in the shell
> script if there are *.rc files around (as we do now).

The idea is surprising me and seems to be a step further that what I wanted to 
do. However perhaps this further step is needed.

So if I understand you well you want something like:

function makemessage
{
  $(XGETTEXT) *.cpp -o $(podir)/kio_floppy.pot
}


This could be an interesting way, as my idea for long-term simplification 
could become as simple as having only:

DIRECTORIES=.
POTFILE=kio_floppy.pot

or for a complex application without extra data

DIRECTORIES=`find . -type d`
POTFILE=myapp.pot

and the calling code could do the rest (including filtering out the .svn 
directories).



Thinking that way, for the short-term change instead of using a 
default_extractrc call, may be it should be a variable:

function makemessage
{
  $(XGETTEXT) *.cpp -o $(podir)/kio_floppy.pot
}
default_extractrc=1

so the calling code could check very easily if it needs to be processed.


>

> I don't really fancy doing this mass conversion in KDE3, but I think we

Well, I think that KDE3 should be left as is. We are not converting the 
Makefile.am files there either.

> should have our scripts check if there is a messages.sh and if there is it
> will trigger the new way and if there is none, it will trigger the old way
> - and for KDE4 we drop support for the old way soonish. I'd even volunteer
> to do the mass conversion in trunk (I have some Makefile parsers at hand :)

Please convert!

Once you have converted all the KDE4 Makefile.am files, you can drop the old 
support immediately.

A mixed trunk/l10n will not be a problem, as the admin directories of the 
modules will be different depending on KDE3 or KDE4. So the need for a check 
for a messages.sh file in KDE4 is only needed for error reporting purposes 
but not needed for a fallback.

>
> Greetings, Stephan

Have a nice day!





More information about the kde-core-devel mailing list