Sat 05 May 2007 04:27:45 PM UTC, comment #10:
This is fixed now. Just can't remember how to explicitly rebuild the po files now.
|
Fri 27 Apr 2007 05:49:48 PM UTC, comment #9:
Yes, I think we're stuck occasionally committing the .po files to save processing time, but for now, it's so fast it's not a problem.
The .gmo files will always be uptodate. The main reason to check in updated files is to reduce processing time.
|
Fri 27 Apr 2007 05:35:21 PM UTC, comment #8:
So, are you suggesting we always commit the updated files ?
If yes I can do this, no problem, just want to be sure we won't
keep committing fake updates.
|
Fri 27 Apr 2007 05:26:38 PM UTC, comment #7:
It already works this way, sortof. The .po files are only updated if any of the source files change. These are only a "base" version, and any changes in the source files gets merged into the base version. Then the .po is processed to make the .gmo file, which is what needs to be loaded at runtime. Occasionally we'll be forced to checkin an update .po file, but as it's always merged with the latest changes, it'll be correct. It you have gettext installed, this all happens very quickly, as Gnash is not a verbose application for most users.
The only way to avoid this step would be to let the .gmo files gets out of sync occasionally with the C++ sources, and remerge them only if the build tree is reconfigured. (ie a build dependancy on the Makefile)
|
Fri 27 Apr 2007 05:11:52 PM UTC, comment #6:
What about having an explicit rule for updating the .po files,
and making sure 'make dist' and 'make distcheck' invokes that rule ?
In that way we can choose wheter to explicitly update the .po
for committing then, and we will be sure they are updated
in every release.
|
Fri 27 Apr 2007 05:08:38 PM UTC, comment #5:
It does turn out the .po must exist, as the new messages get merged into the existing files. If the .po files don't exist, you get an error. So I think the current implementation is correct.
|
Fri 27 Apr 2007 04:55:33 PM UTC, comment #4:
I think John mentioned .po files being actually source code, so belonging to the repository. Did I get that wrong John ?
|
Fri 27 Apr 2007 04:13:30 PM UTC, comment #3:
I threw out the gettextize Makefile, and replaced it with something more modern. Actually we shouldn't have the .po files checked in anyway. If gettext isn't installed, pre built files are used. When using gettext, .po files are always updated if any C++ source files change.
|
Fri 27 Apr 2007 03:55:34 PM UTC, comment #2:
I'm afraid that's not the only reason for a change. gettext manual talked about portions of the files possibly updated due to gettext version mismatch, things like "generated on date xxxy by gettext version wwzz".
If the files are only modified when actual messages change that's fine, we'd just commit the changes in.
|
Fri 27 Apr 2007 03:44:49 PM UTC, comment #1:
The .po files only get changed if any of the source files with strings in them changed. Since the .po files are used to generate the .gmo files that must be loaded by the application at runtime, regenerating them if any of the C++ source files changed seemed the right way to handle the dependencies. if you don't have gettext installed, it uses prebuilt .gmo files instead. So it the .po files aren't updated with string changes to C++ source files, they'll get out of sync. An optional idea was to rebuild only if the Makefile had changed.
|
Fri 27 Apr 2007 07:26:23 AM UTC, original submission:
I think we can live with them being modified by 'make dist'
and 'make distcheck', but modifying them by 'make' seems a bit confusing to me.
|