bug#81332: info/dir and INFO_NONMISC are not gated by DOCLANGS

Vincent Belaïche <[email protected]> Tue, 4 Aug 2026 18:41:31 +0000
Newsgroups gmane.emacs.bugs
Message-ID <AMBP194MB2691FE84B697C4616EADA67584D42@AMBP194MB2691.EURP194.PROD.OUTLOOK.COM>
--_000_AMBP194MB2691FE84B697C4616EADA67584D42AMBP194MB2691EURP_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Dear Eli,

I won't argue any further on whether these three manuals must be in any bui=
ld. I do respect your POV, you know better than I do.

Now, just from a technical POV, we will have to be careful when we get manu=
al translations of some manual (say foo.texi) that is under one of director=
ies emacs, lispref or lispintro, but is distinct from respectively emacs-li=
sp-intro.texi, elisp.texi or emacs.texi.

Say we have manual doc/emacs/foo.texi, and foo is not emacs, and we have so=
me translation of foo.texi to French. So there is some doc/translations/fr/=
emacs/foo-fr.texi and there is some doc/translations/fr/emacs/info_common.m=
k and some doc/translation/default/emacs/info_common.mk that both set foo i=
nto INFO_COMMON list. And emacs will have to be in list TRANSLATED_DIRS. So=
 if emacs subdirectory is in TRANSLATED_DIRS wouldn't this mean that compil=
ation rule of emacs.texi to emacs.info needs to be generated by iterating D=
OCLANG over DOCLANGS and as such setting DOCLANGS to ' ' will disable compi=
ling emacs.texi ? I mean that emacs would also be listed in INFO_COMMON as =
set by doc/translations/default/emacs/info_common.mk.

What would happen when we have the French translation emacs-fr.texi under d=
oc/translations/fr/emacs ? Would it be also mandated to build ? Do we inten=
d that the docstrings links that you referred to in a prior email will poin=
t at the user preferred language manual (so emacs.info or emacs-fr.info dep=
ending on some setting) ?

Does mandating compiling these three manuals in the end boil down to this t=
hat we need some extra pseudo language "mandatory" that would be handled ex=
actly the same as "default" except that DOCLANGS is forced to contain at le=
ast "mandatory" and that a manual cannot be both "default" and "mandatory" =
?

   Vincent.
________________________________
De : Eli Zaretskii <[email protected]>
Envoy=E9 : mardi 4 ao=FBt 2026 14:56
=C0 : Vincent Bela=EFche <[email protected]>
Cc : [email protected] <[email protected]>; [email protected] <8133=
[email protected]>
Objet : Re: bug#81332: info/dir and INFO_NONMISC are not gated by DOCLANGS

> From: Vincent Bela=EFche <[email protected]>
> CC: "[email protected]" <[email protected]>
> Date: Tue, 4 Aug 2026 12:14:49 +0000
>
> IMHO it is not such a good idea to have specific handling for some manual=
s. This makes makefiles more
> complex and hard to maintain.

I respectfully disagree.

> Concerning Eli's point:
>
> > THose 3 manuals must always be built and always be installed,
> > regardless of DOCLANGS.
>
> I acknowledge that some manuals are really needed to be installed in a no=
rmal build. However, on the other
> hand, it should be possible for the aware user to configure the build wit=
hout those manuals. I mean that it
> should be possible to build the Emacs executable on a machine on which th=
e makeinfo tools are not available.
> The Emacs executable should be able to be installed, start and run w/o cr=
ashing even though the mandatory
> manuals are not installed. The user should get some error message, just l=
ike when some application's DLL is
> not there and you cannot load it, one gets an error message telling which=
 DLL is missing.

When makeinfo is not available, it's a separate issue.  We already
provide the Info manuals as part of the release tarballs, so users who
build their own Emacs from a release tarball have no problem with
that.  For building from Git, makeinfo is a prerequisite.

> I understand that this is not the case, and currently makeinfo is a build=
 prerequisite. Please don't take me
> wrong: I am not saying that the user should be anyhow encouraged not to c=
ompile & install the manuals. My
> point is that having some manual build mandated prevents code factorizati=
on in the makefiles, and that also
> prevents aware users to disable the manual building (at their own risks o=
f not getting appropriate documentation
> when using Emacs) to get some minimalistic build. My recommendation is th=
at makeinfo should just be highly
> recommended, but just like the TeX texinfo compiler, should not be absolu=
tely mandated (meaning that it is ok if
> there is some trick like setting DOCLANGS to ' ' to disable manual compil=
ation altogether).

I realize that this makes the build more complex, but having these 3
manuals is from my POV a requirement.  Emacs can run without them, and
will not crash, but we don't want such situation to happen just
because DOCLANGS was set to some value.

--_000_AMBP194MB2691FE84B697C4616EADA67584D42AMBP194MB2691EURP_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
<style type=3D"text/css" style=3D"display:none;"> P {margin-top:0;margin-bo=
ttom:0;} </style>
</head>
<body dir=3D"ltr">
<div class=3D"elementToProof" style=3D"font-family: &quot;Courier New&quot;=
, monospace; font-size: 12pt; color: rgb(0, 0, 0);">
Dear Eli,</div>
<div class=3D"elementToProof" style=3D"font-family: &quot;Courier New&quot;=
, monospace; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class=3D"elementToProof" style=3D"font-family: &quot;Courier New&quot;=
, monospace; font-size: 12pt; color: rgb(0, 0, 0);">
I won't argue any further on whether these three manuals must be in any bui=
ld. I do respect your POV, you know better than I do.</div>
<div class=3D"elementToProof" style=3D"font-family: &quot;Courier New&quot;=
, monospace; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class=3D"elementToProof" style=3D"font-family: &quot;Courier New&quot;=
, monospace; font-size: 12pt; color: rgb(0, 0, 0);">
Now, just from a technical POV, we will have to be careful when we get manu=
al translations of some manual (say foo.texi) that is under one of director=
ies emacs, lispref or lispintro, but is distinct from respectively emacs-li=
sp-intro.texi, elisp.texi or emacs.texi.</div>
<div class=3D"elementToProof" style=3D"font-family: &quot;Courier New&quot;=
, monospace; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class=3D"elementToProof" style=3D"font-family: &quot;Courier New&quot;=
, monospace; font-size: 12pt; color: rgb(0, 0, 0);">
Say we have manual doc/emacs/foo.texi, and foo is not emacs, and we have so=
me translation of foo.texi to French. So there is some doc/translations/fr/=
emacs/foo-fr.texi and there is some doc/translations/fr/emacs/info_common.m=
k and some doc/translation/default/emacs/info_common.mk
 that both set foo into INFO_COMMON list. And emacs will have to be in list=
 TRANSLATED_DIRS. So if emacs subdirectory is in TRANSLATED_DIRS wouldn't t=
his mean that compilation rule of emacs.texi to emacs.info needs to be gene=
rated by iterating DOCLANG over
 DOCLANGS and as such setting DOCLANGS to ' ' will disable compiling emacs.=
texi ? I mean that emacs would also be listed in INFO_COMMON as set by doc/=
translations/default/emacs/info_common.mk.&nbsp;</div>
<div class=3D"elementToProof" style=3D"font-family: &quot;Courier New&quot;=
, monospace; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class=3D"elementToProof" style=3D"font-family: &quot;Courier New&quot;=
, monospace; font-size: 12pt; color: rgb(0, 0, 0);">
What would happen when we have the French translation emacs-fr.texi under d=
oc/translations/fr/emacs ? Would it be also mandated to build ? Do we inten=
d that the docstrings links that you referred to in a prior email will poin=
t at the user preferred language
 manual (so emacs.info or emacs-fr.info depending on some setting) ?</div>
<div class=3D"elementToProof" style=3D"font-family: &quot;Courier New&quot;=
, monospace; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class=3D"elementToProof" style=3D"font-family: &quot;Courier New&quot;=
, monospace; font-size: 12pt; color: rgb(0, 0, 0);">
Does mandating compiling these three manuals in the end boil down to this t=
hat we need some extra pseudo language &quot;mandatory&quot; that would be =
handled exactly the same as &quot;default&quot; except that DOCLANGS is for=
ced to contain at least &quot;mandatory&quot; and that a manual
 cannot be both &quot;default&quot; and &quot;mandatory&quot; ?</div>
<div class=3D"elementToProof" style=3D"font-family: &quot;Courier New&quot;=
, monospace; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class=3D"elementToProof" style=3D"font-family: &quot;Courier New&quot;=
, monospace; font-size: 12pt; color: rgb(0, 0, 0);">
&nbsp; &nbsp;Vincent.&nbsp;&nbsp;</div>
<div id=3D"appendonsend"></div>
<hr style=3D"display:inline-block;width:98%" tabindex=3D"-1">
<div id=3D"divRplyFwdMsg" dir=3D"ltr"><font face=3D"Calibri, sans-serif" st=
yle=3D"font-size:11pt" color=3D"#000000"><b>De :</b> Eli Zaretskii &lt;eliz=
@gnu.org&gt;<br>
<b>Envoy=E9 :</b> mardi 4 ao=FBt 2026 14:56<br>
<b>=C0 :</b> Vincent Bela=EFche &lt;[email protected]&gt;<br>
<b>Cc&nbsp;:</b> [email protected] &lt;[email protected]&gt;; 81332@deb=
bugs.gnu.org &lt;[email protected]&gt;<br>
<b>Objet :</b> Re: bug#81332: info/dir and INFO_NONMISC are not gated by DO=
CLANGS</font>
<div>&nbsp;</div>
</div>
<div class=3D"BodyFragment"><font size=3D"2"><span style=3D"font-size:11pt;=
">
<div class=3D"PlainText">&gt; From: Vincent Bela=EFche &lt;vincent.b.1@hotm=
ail.fr&gt;<br>
&gt; CC: &quot;[email protected]&quot; &lt;[email protected]&gt;<br=
>
&gt; Date: Tue, 4 Aug 2026 12:14:49 +0000<br>
&gt; <br>
&gt; IMHO it is not such a good idea to have specific handling for some man=
uals. This makes makefiles more<br>
&gt; complex and hard to maintain.<br>
<br>
I respectfully disagree.<br>
<br>
&gt; Concerning Eli's point:<br>
&gt; <br>
&gt; &gt; THose 3 manuals must always be built and always be installed,<br>
&gt; &gt; regardless of DOCLANGS.<br>
&gt; <br>
&gt; I acknowledge that some manuals are really needed to be installed in a=
 normal build. However, on the other<br>
&gt; hand, it should be possible for the aware user to configure the build =
without those manuals. I mean that it<br>
&gt; should be possible to build the Emacs executable on a machine on which=
 the makeinfo tools are not available.<br>
&gt; The Emacs executable should be able to be installed, start and run w/o=
 crashing even though the mandatory<br>
&gt; manuals are not installed. The user should get some error message, jus=
t like when some application's DLL is<br>
&gt; not there and you cannot load it, one gets an error message telling wh=
ich DLL is missing.<br>
<br>
When makeinfo is not available, it's a separate issue.&nbsp; We already<br>
provide the Info manuals as part of the release tarballs, so users who<br>
build their own Emacs from a release tarball have no problem with<br>
that.&nbsp; For building from Git, makeinfo is a prerequisite.<br>
<br>
&gt; I understand that this is not the case, and currently makeinfo is a bu=
ild prerequisite. Please don't take me<br>
&gt; wrong: I am not saying that the user should be anyhow encouraged not t=
o compile &amp; install the manuals. My<br>
&gt; point is that having some manual build mandated prevents code factoriz=
ation in the makefiles, and that also<br>
&gt; prevents aware users to disable the manual building (at their own risk=
s of not getting appropriate documentation<br>
&gt; when using Emacs) to get some minimalistic build. My recommendation is=
 that makeinfo should just be highly<br>
&gt; recommended, but just like the TeX texinfo compiler, should not be abs=
olutely mandated (meaning that it is ok if<br>
&gt; there is some trick like setting DOCLANGS to ' ' to disable manual com=
pilation altogether).<br>
<br>
I realize that this makes the build more complex, but having these 3<br>
manuals is from my POV a requirement.&nbsp; Emacs can run without them, and=
<br>
will not crash, but we don't want such situation to happen just<br>
because DOCLANGS was set to some value.<br>
</div>
</span></font></div>
</body>
</html>

--_000_AMBP194MB2691FE84B697C4616EADA67584D42AMBP194MB2691EURP_--