Am Dienstag, 30. Januar 2018, 00:34:18 CET schrieb Dylan Baker:
> Quoting Marc Dietrich (2018-01-27 06:36:51)
>
> > Hi Dylan,
> >
> > Am Donnerstag, 25. Januar 2018, 20:32:23 CET schrieb Dylan Baker:
> > > Currently meson implements the same logic as SCons for translations,
> > > namely it doesn't do them. This patch changes meson to use logic more
> > > like autotools, and generate translations. To do this we have to go
> > > behind meson's back a bit, and wrap the whole thing up in a single
> > > python script.
> > >
> > > Meson has a module for gettext translations, but it assumes that one
> > > will have a pot file, and then .mo translations will be generated and
> > > checked into the source repo (or generated by hand using custom ninja
> > > targets before building), mesa assumes that the targets will be
> > > regenerated on each invocation of make or ninja. I think this can be
> > > fixed upstream, but in the mean time this adds support for using
> > > translations.
> >
> > I have some patch sitting in my local tree which also addresses this
> > problem. It is a bit shorter and doesn't require an external script. I
> > initially tried to solve this by adding some custom targets mostly in
> > order to learn some meson. Unfortunately, I didn't came far. I also tried
> > the i18n module, but as you said, there are still some features missing.
> >
> > Nevertheless, here is my solution using run_commands instead of external
> > script. The advantage maybe better maintainability:
> >
> > diff --git a/src/util/xmlpool/meson.build b/src/util/xmlpool/meson.build
> > index 97693fac8c..91f2b025f6 100644
> > --- a/src/util/xmlpool/meson.build
> > +++ b/src/util/xmlpool/meson.build
> > @@ -18,11 +18,36 @@
> >
> > # OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
> > IN
> >
> > THE
> >
> > # SOFTWARE.
> >
> > +langs = ['ca', 'es', 'de', 'nl', 'sv', 'fr']
> > +deps = []
> > +pot = 'xmlpool.pot'
> > +out = meson.current_build_dir()
> > +in = meson.current_source_dir()
> > +
> > +xmlpool_pot = custom_target(
> > + pot,
> > + build_by_default : true,
> > + input : 't_options.h',
> > + output : pot,
> > + command : ['xgettext', '-LC', '--from-code=utf-8', '-o', '@OUTPUT@',
> > '@INPUT@'],
> > +)
> > +
> > +foreach l : langs
> > + po = l+'.po'
> > + mo = '@0@/LC_MESSAGES/options.mo'.format(l)
> > + message('Merge new strings @0@ into @1@'.format(po, pot))
> > + run_command('msgmerge', '-o', join_paths(out, po), join_paths(in, po),
> > pot) + message('Updating (@0@) @1@ from @2@.'.format(l, mo, po))
> > + run_command('mkdir', '-p', join_paths(out, l, 'LC_MESSAGES'))
> > + run_command('msgfmt', '-o', join_paths(out, mo), po)
> > + deps += po
> > +endforeach
> > +
>
> Hi Marc,
>
> I'm not a huge fan of this, it adds three unix specific dependencies, and
> every time ninja is run we'll call mkdir and msgfrmt multiple times. Iyes, I understand that run_command is not portable. It is better to use python functions, even if it makes it complicated. > really like the idea of fixing the i18n module to return custom targets > instead of run targets, but that's going take some work and wont come until > a newer version of meson. Maybe the thing to do is to just rely on distros > manually updating the mo files. I have to admit that I don't understand how these translations work. I wonder why mesa doesn't just ship <share-dir>/locale/<lang>/LC_MESSAGES/<module>.mo files as many others do (and which would also be supported by meson). Instead, these files get magically included in the binaries. So a second option would be to rewrite this code to make use of external .mo files. Marc
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
