Okay, I'll switch to an array. I'm used to hashes, and personally find it just as readable, but maybe not.. And efficiency is indeed not an issue for this non-runtime code.
On 2018-04-13 10:42, Iain Lane wrote:
> OK, a slight review, it's confusing that --domain only works for
> meson; is there any reason not to make that option cover other build
> systems too?
My thought was that the purpose of adding it was to offer a way to compensate for the ambiguity wrt some Meson packages. So the way it's currently done, you can only set a domain from debian/rules which the introspect command finds. Eliminates the risk that a package maintainer screws it up. ;)
If we'd switch to a true override, where you can set any domain from debian/rules, it would make sense to include other build systems. That might be useful for cases where a gettext domain exists, but the dh_translations code fails to find it for some reason.
Okay, I'll switch to an array. I'm used to hashes, and personally find it just as readable, but maybe not.. And efficiency is indeed not an issue for this non-runtime code.
On 2018-04-13 10:42, Iain Lane wrote:
> OK, a slight review, it's confusing that --domain only works for
> meson; is there any reason not to make that option cover other build
> systems too?
My thought was that the purpose of adding it was to offer a way to compensate for the ambiguity wrt some Meson packages. So the way it's currently done, you can only set a domain from debian/rules which the introspect command finds. Eliminates the risk that a package maintainer screws it up. ;)
If we'd switch to a true override, where you can set any domain from debian/rules, it would make sense to include other build systems. That might be useful for cases where a gettext domain exists, but the dh_translations code fails to find it for some reason.
Should I change it to a true override, so to say?