[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