[Mesa-dev] [PATCH v2] meson: generate translations for driconf

[Marc Dietrich]

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 at .'.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. I

yes, 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20180131/da440a5a/attachment.sig>