[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Makevars handling in 'bootstrap'

From: Bruno Haible
Subject: Makevars handling in 'bootstrap'
Date: Sun, 05 May 2019 21:30:10 +0200
User-agent: KMail/5.1.3 (Linux/4.4.0-145-generic; KDE/5.18.0; x86_64; ; )

Hi Paul,

Tim Rühsen tells me that one of the problems he had yesterday with Makevars
is that 'bootstrap' overwrites po/Makevars with one that substitutes values
from bootstrap.conf.

This has several drawbacks:
  * In the gettext documentation, Makevars is documented [1] as a file that
    the maintainer has to create. With 'bootstrap', it is not documented
    what to do with the file.
  * In the Makevars.template, there are comments explaining each variable
    that can be set. 'bootstrap' allows the user to set EXTRA_LOCALE_CATEGORIES,
    COPYRIGHT_HOLDER, MSGID_BUGS_ADDRESS, but none of these has a comment
    in the template bootstrap.conf.
  * In the Makevars.template, there are other variables: PACKAGE_GNU,
    through bootstrap.conf. Tim has had to find a workaround in order to
    be able to set PACKAGE_GNU.
  * The Makevars approach supports packages with multiple po/ directories
    (and thus multiple domains). The 'bootstrap' does not. But it has a
    special case, probably coming from bison's need, to handle a
    $package-runtime domain.

I would suggest to entirely remove the Makevars handling from 'bootstrap',
and instead let the maintainers create a Makevars file by hand, according
to the documentation - like they also create configure.ac and Makefile.am
files by hand.

I'm not responsible for 'bootstrap'. But I'm responsible for gettext,
and here what I see is that 'bootstrap' attempts to offer similar customizations
as Makevars does but does so in a way that introduces drawbacks and conflicts
with the gettext documentation.


[1] https://www.gnu.org/software/gettext/manual/html_node/po_002fMakevars.html

reply via email to

[Prev in Thread] Current Thread [Next in Thread]